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FOREWORD 


The Nascom System Development Plan (NSDP) pro- 
vides information on the charter, organization, ca- 
pabilities and future plans concerning the NASA 
Communications (Nascom) Network. The NASA 
Communications Division, Code 540 (GSFC), is re- 
sponsible for the planning, engineering, and op- 
eration of the Nascom Network. 

As implemented by GSFC management, the NSDP 
method of documentation serves several purposes. 
As a continuing document, revised and reissued 
annually, it is intended to serve as a communica- 
tions medium for disseminating Nascom Network 
capabilities and development planning informa- 
tion. It is intended to promote organized, coordi- 
nated program planning and implementation. In 
addition, the NSDP facilitates management direc- 
tion and control, and also provides a logical means 
for obtaining necessary approval of major Net- 
work changes from NASA Headquarters through 
interaction between updates. This document is in- 
tended to fulfill requirements of NASA Manage- 
ment Instruction 2520. ID and other NASA Head- 
quarters instructions. 

The NSDP consists of seventeen sections. Sections 
1 through 14 comprise the basic document and 


contain a description of the present Nascom Sys- 
tem's operational capabilities. Section 15 de- 
scribes the support configurations provided to the 
various networks served by Nascom. Sections 16 
and 17 summarize information concerning 
mission-unique support planning and 5-year Net- 
work development planning, respectively. 

Detailed Network information on current circuit 
status, individual project support and various oth- 
er NSDP backup data are maintained by the NASA 
Communications Division for internal use. 

All Nascom Network users, mission and program 
planners, and managers are encouraged to pro- 
vide comments relative to this document and mis- 
sion support requirements to the NASA Commu- 
nications Division, Code 540, Goddard Space Flight 
Center, Greenbelt, Maryland 20771. This organi- 
zation will receive its formal requirements infor- 
mation through official documentation sources. 
Notification of program changes may be made at 
any time to the NASA Communications Division in 
accordance with prescribed procedures in order 
that these may be reflected in the NSDP and, 
where necessary, in Network implementation. 
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effective information transport services to meet 
the continuously evolving requirements of NASA's 
spaceflight projects. 

1.5.3 OPERATIONS MANAGEMENT BRANCH 

The Operations Management Branch (Code 542) is 
responsible for the overall technical and oper- 
ational management of the NASA Communica- 
tions Network. To execute these responsibilities, 
the Branch is comprised of three sections: Mission 
Planning, Communications Management, and 
Communications Services. 

1.5.3.1 Mission Planning Section . The Mission 
Planning Section (Code 542.1), is tasked with re- 
viewing all flight projects communications re- 
quirements to ensure that the telecommunications 
needs of the projects are met. It initiates actions 
to provide new communications services, if re- 
quired, with due consideration given to the avail- 
ability (or non-availability) of existing network re- 
sources. The section provides liaison between the 
technical implementation organizations and the 
flight projects while the service is being planned, 
engineered, and implemented. This section is also 
responsible for developing and publishing the 
Nascom System Development Plan (NSDP) for the 
Nascom Division. 

1. 5.3.2 Communications Management Section . 
The Communications Management Section (Code 
542.2) provides operational management of the 
Nascom Network on a 24 hour per day schedule, 
ensuring that all supporting elements are avail- 
able to meet project requirements. It provides li- 
aison between Nascom and the commercial carri- 
ers supplying its circuits, thus ensuring the provi- 
sion of reliable telecommunications services. It 
furnishes all the technical control functions re- 
quired to maintain the network in a constant state 
of readiness to meet all telemetry, command, and 
other operational data and voice signal transport 
requirements. This section also has the responsi- 
bility for managing the GSFC Communications Se- 
curity (COMSEC) Account. 

1. 5.3.3 Communications Services Section . The 
Communications Services Section (Code 542.3) 
provides technical contract management func- 
tions for leased telecommunications services and 
equipment, equipment purchases, and support 
service contracts. It provides guidance for the de- 
velopment of telecommunications performance 
standards and measurement techniques for 
Nascom Network circuitry. The section analyzes 
network performance and develops circuit perfor- 
mance data for use in the circuit procurement and 
rebate process. 


1.5.4 TELECOMMUNICATIONS BRANCH 

The Telecommunications Branch, Code 543, man- 
ages the requirements, system planning, design, 
maintenance and operation of the "GSFC Tele- 
communications Network." This network includes 
voice/data systems, local area communications 
networks, video systems, electronic mail facilities, 
office automation systems and cable plant facili- 
ties located at GSFC, NASA Headquarters, and the 
Wallops Flight Facility (WFF). 

The Telecommunications Branch is organized 
functionally as indicated in the following para- 
graphs. 

1. 5.4.1 Closed Circuit Televjsion (CCTV)/Datacom . 
The Closed Circuit Television (CCTV)/Datacom 
function provides continuous support for the GSFC 
control centers including the distribution of video, 
timing, and data. It maintains and operates TV 
Central and the centerwide GSFC RF video distribu- 
tion network. Additionally, it provides TV engi- 
neering, transmission and production support for 
GSFC and NASA Headquarters. 

1.5.4.2 NASA Select TV Network . The NASA Select 
TV Network function provides a maintenance and 
operation service for the NASA Select TV system. 
This service, provided five days per week, includes 
the production, scheduling and broadcasting of 
the Space Transportation System (STS) events, in- 
ternal NASA educational and scientific projects, 
and other NASA sponsored video products. 

1. 5.4.3 Office of Space Communications (Head- 
quarters Code O) Support . This function provides 
for the installation, maintenance, and operation 
of the audio/video distribution system at the new 
NASA Headquarters building. 

1. 5.4.4 GSFC Local Area Communications Network 
(LACN) . This function provides for the overall 
maintenance and operation of the GSFC LACN. 
Additionally, it is significantly involved in assessing 
applications of new technology and evaluating 
systems for operational implementation at GSFC. 

1. 5.4.5 GSFC Institutional Support . This function 
provides for GSFCMail service support and main- 
tains the extensive data base for the GSFC Inter- 
connect Telecommunication System (ITS) (ROLM) 
telephone system. It also coordinates, with MSFC, 
all GSFC and Wallops requirements for PSCN ser- 
vice. It provides the technical support necessary to 
provide PSCN tail circuit extensions at GSFC and 
WFF. Related to this is the responsibility for instal- 
lation and maintenance of cable plant facilities at 
GSFC, NASA Headquarters, and the WFF for sup- 
port of institutional and scientific programs. 
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1. 5.4.6 Public Affairs Office (PAOWisitor Center . 
This function provides repair and preventative 
maintenance for all the audio/visual equipment in 
the GSFC Visitors Center. 

1.6 NASCOM SYSTEM DEVELOPMENT PLAN 

1.6.1 CONCEPT, PHILOSOPHY, AND USE FOR 
NSDP DOCUMENTATION 

The NSDP is a management document containing 
the approved plan for establishing and 
maintaining the Nascom Network System. Its 
preparation and maintenance is required by 
NMI 2520.1 D. The concept in developing the NSDP 
is to provide a document concerning the Nascom 
Network that can be useful to a wide range of 
readers from NASA management to the various 
levels of Network users. Aside from serving as a 
technical reference, the NSDP can also serve as an 
introductory paper or tutorial for those who plan 
to use the Nascom Network. The NSDP reflects 
Nascom's interpretation of the communications 
services required to support NASA programs in 
existing and planned implementation. The NASA 
Communications Division does not evaluate 
program requirements, but provides for those 
validated requirements that have been funded by 
NASA Headquarters. 

1.6.2 SCOPE 

The NSDP covers the system description of Nascom 
systems, existing capabilities and requirements for 
these systems, plans and development activities 
during the fiscal year, plans for the ensuing fiscal 
year and the following five years, and descriptions 
of support provided to various NASA projects and 
missions. 

1.6.3 CONTENT 

Section 1 provides information on the Nascom 
charter and management, and Section 2 on pro- 
curement and resource planning. Sections 3 
through 14 describe the various Nascom systems, 
circuit configurations, and arrangements. Section 
15 provides information on NASA networks (other 
than the Nascom Network) and the extent of 
Nascom support. Section 16 describes Nascom 
planning for individual NASA missions. Section 17 
provides information on development of Nascom 
systems that are planned or in the process of im- 
plementation to meet future program require- 
ments. 

1.6.4 RESPONSIBILITY 

The Mission Planning Section of the NASA Com- 
munications Division is responsible for the publica- 
tion, maintenance, and issuance of the NSDP. The 


Chief of the NASA Communications Division is, 
however, the signature authority for approving 
the NSDP, and the NASA authority responsible for 
the prompt issuance of revisions and necessary 
page changes to maintain the NSDP in an ade- 
quate and current status. 

1.6.5 USE OF THE NSDP 

As stated in the Foreword and in paragraph 1.6.1, 
the NSDP is a multipurpose document. It is used by 
Nascom management to meet a requirement of 
NMI 2520.1D, and as a medium for disseminating 
information to promote coordinated NASA net- 
works and program planning. The NSDP is also 
used by NASA Headquarters in support of the bud- 
get presentation. 

1 .6.6 NSDP PREPARATION 

Preparation of the NSDP necessitates that commu- 
nications requirements from all programs be re- 
ceived and consolidated into an overall Nascom 
Network plan in a timely manner. Nascom devel- 
opment plans are coordinated with field installa- 
tions and the NASA centers before implementa- 
tion. Information is promulgated through publica- 
tion and distribution of the NSDP. 

1 .6.7 NSDP PUBLICATION CYCLE 

The NSDP production schedule has, to date, in- 
cluded the document being reissued on an annual 
basis during the first month of the fiscal year with 
a mid-year update (change pages) being provided 
as of the seventh month of the fiscal year. The FY 
94-1 reissue and FY 94-2 mid-year update were the 
last to follow this schedule. Following this issu- 
ance, FY 94-2 update, the NSDP will be produced 
and reissued on an annual basis only, the next re- 
issue being due as of April 1995. 

1.7 NASCOM USER REQUIREMENTS PLANNING 
1.7.1 SOURCE DOCUMENTATION 

The following paragraphs identify the major 
source documents that are used to establish the 
requirements for support of spaceflight projects 
and missions. These documents will include 
operational ground communications support 
requirements, many of which may directly or 
indirectly specify Nascom systems support for the 
respective mission. Requirements are documented 
in two different ways: the Universal Documenta- 
tion System (UDS) for manned flight missions and 
the Mission Requirements Request (MRR)/Detailed 


NASCOM CHARTER AND MANAGEMENT 1-8 


540-030 

FY94-2 


Mission Requirements (DMR) Document for 
unmanned space projects and for suborbital and 
aeronautical flight projects. The operational 
communication requirements, originally 
documented, approved, and maintained in the 
UDS and MRR/DMR, are used by the Mission 
Planning Section, Code 542.1, for Nascom's 
mission-unique planning requirements activity. 

1.7.1. 1 Universal Documentation System . The fol- 
lowing paragraphs describe the UDS. 

a. UDS Basis Document . NMI 8610.10B, dated 
December 19, 1991, prescribes use of the UDS. The 
UDS provides a system for managing operational 
support requirements for manned flight missions 
including the requesting of support and the re- 
sponding to those requests. The UDS is applicable 
to NASA Headquarters and the NASA field installa- 
tions (including GSFC/Nascom) and DoD installa- 
tions in accordance with the NASA/ DoD Memo- 
randum of Understanding (MOU) on Management 
and Operation of the Space Transportation System 
and its subagreements 

b. UDS Description . The UDS consists of three 
levels of documentation in six documents: 

(1) Level 1: Program Introduction Docu- 
ment (PID)/Statement of Capability Document 
(SCD). The PID and SCD are the long-lead-time 
Level I Program requirements and response docu- 
ments initiated at the start of a new program and 
signed by the cognizant Program Associate Ad- 
ministrators. These documents are generated and 
maintained for the Space Shuttle Program (SSP). 
They are revised as required according to ap- 
proved Level I and Level II change procedures to 
reflect changes both in requirements and commit- 
ments. 

(2) Level 2: Program Requirements Docu- 
ment (PRD)/Program Support Plan (PSP). Within 
the scope of the requirements and responses de- 
veloped in the PID and the SCD, these program 
Level II documents define requirements and re- 
sponses for prelaunch, launch, flight, landing and 
postlanding operations. These documents are 
used for direct support requests among NASA and 
DoD elements. The Space Shuttle requires launch 
and landing PRD's, prepared and approved by 
Kennedy Space Center (KSC), and flight PRD's, ap- 
proved and maintained by Johnson Space Center 
(JSC) for flights launched from KSC. Each PRD con- 
sists of two volumes, Volume 1 containing Shuttle 
support requirements, and Volume 2 containing 
cargo/payload requirements, with separate an- 
nexes for each payload. The PSP is the support 
agency response commitment to PRD require- 
ments. 


There are also provisions for an Expedited 
Operations Requirements (EOR) system for 
unanticipated prelaunch test, launch, flight, and 
landing requirements to be requested and 
responded to in an expedited mode when 
essential to maintain continuing operations. 
These are known as Launch Support Requirements 
(LSR) and Flight Support Requirements (FSR) for 
the respective PRD's. 

(3) Level 3: Operations Requirements 

(OR) and Operations Directives (OD). Within the 
scope of the requirements and responses devel- 
oped in the PRD and PSP, these program Level III 
documents define requirements and responses in 
sufficient detail to be used for developing oper- 
ational documentation for mission support. As the 
OR presents the detailed requirements of a mis- 
sion or activity, the OD supplies the supporting 
agency's response commitment. 

(4) OSC and GSFC Role: OSC is responsible 
for overall management and commitment for sup- 
port of NASA's tracking and data acquisition, and 
communications and data systems. OSC responds 
to Level I Program support requirements for 
manned flight missions through the Associate Ad- 
ministrator for Space Communications. OSC re- 
sponds to Level II and Level III program support re- 
quirements through the Goddard Space Flight 
Center. 

c. UDS Requirements Control . All Space 
Shuttle requirements are documented in the UDS. 
Requirements control starts with JSC as the 
requestor for MO&DSD (Code 500) support 
services, which includes Nascom. The Flight 
Mission Support Office (Code 501) is responsible 
for preparing the UDS system OR document and 
their Mission Support Manager (MSM) or Mission 
Operations Manager (MOM), as applicable, coor- 
dinates with the Mission Planning Section (Code 
542.1) for responses to requirements for Nascom 
Network services. 

d. Automated Support Requirements System . 
An Automated Support Requirements System 
(ASRS) has been implemented for automated pro- 
cessing and electronic mailbox distribution of re- 
quirements. ASRS is mandated by the newly issued 
NMI 8610.108 except where classified require- 
ments and responses in support of classified DoD 
payloads are concerned; in the latter case, manual 
documentation of requirements and responses 
employing UDS formats is used. This has been nec- 
essary to accommodate the large quantity of re- 
quirements and changes generated by multiple 
flight missions and payloads. Data bases for both 
launch and landing, and flight operations support 
requirements reside in host computers at KSC. 
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Compatible interacting terminals are located at 
various NASA centers and DoD locations. 

e. UPS Handbook . The UDS Handbook, pub- 
lished in three volumes, describes the total UDS 
structure in Volume 1, Levels 2 and 3 sample for- 
mats in Volume 2, and Levels 2 and 3 response da- 
ta in Volume 3. Handbook Supplement 2 describes 
the procedures for electronic processing of Levels 
1, 2, and 3 documents. 

1.7. 1.2 Requirements Documentation Process for 
Unmanned Space. Suborbital, and Aeronautical 
Missions . The following paragraphs describe the 
process for obtaining use of OSC capabilities to 
support unmanned space missions, sub-orbital 
missions, and aeronautical missions. 

NOTE 

The process herein described is that 
prescribed by NMI 8430. 1C; it applies 
to missions for which planning com- 
menced subsequent to the issuance 
of this NMI (December 31, 1991). 
Missions for which planning com- 
menced under provisions of NMI 
8430.1B (prior to 31 December 1991) 
will continue to use the procedures 
and documentation prescribed by 
that NMI. 

a. General . This requirements process is both 
iterative and interactive, providing the mechanism 
for customers to obtain use of OSC capabilities 
throughout the mission life-cycle. The objective of 
the process is two fold: (1) attaining timely deter- 
mination of the requirements for OSC support and 
(2) enabling OSC to develop cost and schedule 
baselines. 

The customer is expected to initiate early 
coordination with OSC prior to the end of Phase A 
studies. This early interaction with OSC is intended 
to (1) provide the customer with knowledge of 
OSC capabilities, (2) identify requirement trade- 
offs and alternatives, and (3) provide OSC with 
information that may influence its long-range 
planning. This early coordination activity precedes 
any formal requirements documentation from the 
customer to OSC. 

b. Mission Requirements Request . The MRR 
is a concise summary document designed to 
identify the project's top-level requirements. The 
format to be used will be provided to the customer 
by OSC during the early coordination process. As 
its Phase A studies are concluding, a customer 
requiring OSC capabilities forwards its MRR, 


signed by the customer's Associate Administrator 
(or equivalent level if non-NASA) to the Associate 
Administrator/Space Communications. If new OSC 
capabilities are required, then the MRR must be 
submitted in sufficient time to allow for obtaining 
any budget authority necessary for 
implementation of the new capabilities. 
Whenever significant changes to customer 
requirements become known, the customer must 
update the MRR by submitting appropriate 
addenda to OSC. 

c. MRR Acknowledgement Letter . In 
response to the MRR, OSC provides an Acknow- 
ledgement Letter in which are contained the 
following items: (1) confirmation of receipt of the 
MRR by OSC, (2) designation of the point-of- 
contact within OSC, (3) designation of OSC's Lead 
Center and direction to that Center to formally 
develop plans to meet the customer's 
requirements, and (4) designation of the Capacity 
Projection Plan (CPP) as the primary document 
summarizing how OSC's planned capability and 
capacity satisfies the customer's mission 
requirements. 

d. Capacity Projection Plan . The CPP is the 
OSC document which presents to all customers a 
projection of their demands measured against the 
available supply of OSC capabilities and capacities. 
Issued semi-annually consistent with the NASA 
budget cycle, the CPP lists all projects for which 
MRRs have been received and indicates the extent 
to which each project's requirements may be satis- 
fied. The CPP also identifies any capacity and ca- 
pability shortfalls requiring resolution. 

e. Detailed Mission Requirements Document . 
The DMR documents the customer's detailed 
requirements and includes the corresponding OSC 
plans for meeting those requirements. This 
document is the source of detailed requirements 
and plans needed by lower levels to guide their 
implementation activities. Requirements in the 
DMR are traceable to the MRR; whenever a 
requirement change impacts a planned OSC 
capability or capacity, an update is issued by the 
customer. The DMR is prepared and approved 
jointly by the customer's project manager and the 
OSC Lead Center's representative. Issued by the 
customer at the time of Phase C/D approval, the 
DMR is then used by OSC to baseline mission 
requirements and the corresponding cost and 
schedule for implementing any new capacity 
and/or capability required by the mission. 

Where Goddard Space Flight Center is designated 
OSC's Lead Center, detailed requirements are pro- 
cessed by Code 501's applicable Mission Oper- 
ations Manager (MOM) or Mission Support Man- 
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ager (MSM). The MOM or MSM, in turn, formally 
coordinates any requirements for Nascom services 
with Nascom's Mission Planning Section. As a 
member of the MOM's or MSM's team, Nascom 
provides capability and capacity information to 
Code 501 for inclusion in Code 500's "responses" 
to the mission's requirements. 

1.7. 1.3 DELETED 


1 .7.1.4 Other Documentation . The other docu- 
ments that specify the ground operational com- 
munication requirements for the Nascom Network 
to support a NASA project or mission include: 

a. NMI 8410.3, Tracking and Data Relay Sat- 
ellite System (TDRSS): Use and Reimbursement 
Policy for Non-U.S. Government Users, dated 
March 3, 1983. 

b. GSFC-Level I Requirements, Code 500 Sys- 
tems Management. 

1.7.2 NASCOM PARTICIPATION 

1.7.2.1 Nascom Inputs . The Mission Planning Sec- 
tion, Code 542.1, provides inputs to planned sup- 
port for response documentation prepared by 
GSFC MO&DSD, Codes 501, 502, and 530. It also 
provides inputs to Jet Propulsion Laboratory's (JPL) 
managers for the various DSN-supported missions, 
via the DSN/Ground Communications Facility (GCF) 
Mission Coordination Group at JPL. The Mission 
Planning Section has varying degrees of participa- 
tion in the drafting of the original Level 1 and 2 
ground communications requirements section of 
the PRD's and MRR's, through participation in ad 
hoc support planning working groups. Nascom 
may also provide inputs concerning ground com- 
munications to the development of ancillary re- 
quirements documentation, such as the Payload 
Integration Plans (PIP) prepared by JSC, which are 
preliminary to PRD annex documentation for STS 
payload mission requirements. 

1. 7.2.2 NSDP Reportage . The requirements for 
approved or planned future NASA missions as re- 


flected in GSFC MO&DSD level planning and NASA 
mission models, as well as future ongoing mission 
phase support requirements, are summarized in 
Sections 16 and 17 of this document. 

1.7.3 INTEGRATION OF REQUIREMENTS 

This paragraph describes the practices and proce- 
dures observed by Nascom in integrating the var- 
ious communication requirements of the 
spaceflight missions during the planning and im- 
plementation phases. The manner in which the 
common-user Nascom Network is configured to 
meet necessary communication requirements for 
the various missions supported by the STDN and 
DSN stations is contained in Sections 3 through 14 
of the NSDP. The integration of requirements for 
the communications channels and facilities is de- 
scribed in the following paragraphs. 

1.7.3.1 Communication Channels . The actual 
number and type of communication channels re- 
quired fora network station are determined large- 
ly through continuing consultation and review 
with the project and program planners, Ground 
Network (GN), SN and DSN GCF planners, and the 
NASA Communications Division, based on the vali- 
dated, mission-related communication require- 
ments. 

1.7.3.2 Facilities . The number and type of facili- 
ties provided in the common-user portions of the 
network are ultimately determined by the NASA 
Communications Division, based upon the limita- 
tions of facilities actually available, budgetary con- 
straints, carefully considered circuit sharing, mis- 
sion traffic, and scheduling criteria, as provided by 
the program planners. 

1.7.4 FUNDING 

1. 7.4.1 Recurring Charges . The major portion of 
Nascom Network operating costs consists of recur- 
ring charges for full-period (24 hour/day) lease of 
various types of point-to-point telecommunication 
services from domestic and foreign common car- 
riers. These are carried in the operations budget. 
Also carried in the operations budget are opera- 
tor, switching systems software, maintenance, en- 
gineering and operational support services. 

1.7.4.2 Eouipment Budget . An equipment bud- 
get provides for government-furnished voice, data 
modem, and TTY terminals, and switching, moni- 
toring, and test facilities required for cost- 
effective use and operational control of the com- 
munication channels that cannot otherwise be 
provided through lease from the common carriers. 
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1.7.4.3 Variations . The fiscal year-to-yearfunding 
level changes projected in the overall operations 
budget for leased channels (domestic and overseas 
carriers) reflect the net effect of numerous antici- 
pated circuit deletions, additions, or replacement 
actions, tariff revisions, monetary exchange rate 
variations, state-of-the-art developments, etc. 
Therefore, these overall budgetary year-to-year 
variations normally may not be correlated with 
particular project requirements or system changes. 

1. 7.4.4 Sources . Funding of the Nascom oper- 
ational network is provided through the OSC, 
Code O, NASA Headquarters. In addition, some 
services are provided, on a reimbursable basis, to 
NASA projects; experimenter and commercial in- 
terests; and foreign governments and interests. 
This reimbursement is based on the actual cost of 
the service. Funding responsibility remains with 
the organization requiring the service on a con- 
tinuing basis. 

Additional information regarding OSC-funded 
categories for Nascom-obtained resources is con- 
tained in Section 2. Detailed Nascom budgetary 
information is contained in the GSFC Project Op- 
erating Plans (POP) and is supported by the current 
GSFC MO&DSD Work Authorization Documents 
(WAD). Information on network development re- 
lated to the current Nascom portion of the WAD 
may be found in Section 17 of this document. 

Deviation from the approved program as set forth 
in the Nascom WAD (exceeding $100,000 annual 
cost) must have concurrence of NASA Headquar- 
ters. All changes involving unique project commu- 
nications will be coordinated with the cognizant 
field installation, regardless of size. 

1.8 NASCOM POLICIES AND PRACTICES 

1.8.1 MANPOWER 

This paragraph describes the role of the NASA 
Communications Division and the contractor in 
providing manpower for implementing the var- 
ious activities of the Nascom Network. 

1. 8.1.1 Government Role . The majority of NASA 
Communications Division government-employed 
personnel are located at GSFC engaged in the 
planning, engineering design, technical manage- 
ment, and operational direction of the Network. 

1. 8.1.2 Contractor Support . Government man- 
power is supplemented through contracts gener- 
ally providing coordinated program support for 
engineering services, network planning and ana- 
lysis, switching computer programming support, 


and communication controllers and operators at 
GSFC. The prime contracts for providing these ser- 
vices are described as follows: 

a. The Systems, Engineering, and Analysis 
Support (SEAS) contractor is responsible for pro- 
viding general systems engineering support ser- 
vices to Code 540 which include system engineer- 
ing, installation monitoring, engineering, and Ac- 
ceptance Test (AT) monitoring. 

b. The Network Mission Operations Support 
(NMOS) contractor is responsible for providing 
general systems operations support services to 
Code 540 which include supervisors and operators 
to man positions on a 24-hour-per-day, 7-day-per- 
week basis to perform the day-to-day mainten- 
ance and operations (M&O) functions. 

c. At overseas Nascom Interface Facilities, op- 
erations and maintenance personnel are provided 
through NASA contract arrangements with respec- 
tive foreign governments or agencies. 

d. The operationally oriented personnel are 
provided at the remote Nascom Interface Facilities 
and in the project control centers by the interfac- 
ing user organizations. 

1 .8.2 DELEGATION OF AUTHORITY 

The Director, GSFC, for reasons of economy, work- 
load, and responsiveness to project requirements, 
may request the cognizant field installation to im- 
plement the required operational long-line com- 
munications facilities and services. This may in- 
clude provision for the applicable item in the ap- 
propriate program/project budget. It does not al- 
ter the requirement for the Director, GSFC, to con- 
cur in the technical adequacy of the planned facili- 
ties and services. 

1.8.3 CONFIGURATION CONTROL MANAGE- 
MENT 

This paragraph describes the makeup and work- 
ings of the Configuration Control Board (CCB). 

1.8. 3.1 Configuration Control Board . The 
MO&DSD has delegated the authority for the 
management of the Nascom Network configura- 
tion control to the CCB, which reports to the NASA 
Communications Division. The CCB is chaired by 
the Associate Division Chief and is composed of 
the Branch and Section Heads of the Division. The 
purpose of the CCB is to ensure that all proposed 
configuration changes to the Nascom Network sat- 
isfy the system performance necessary to meet 
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3.2.2 CIRCUIT SWITCHING SYSTEM 

Circuit switching is the routine operational 
connection of one circuit to another performed by 
Nascom in response to schedules or real-time 
requests. It may be accomplished in several ways, 
depending on the circuits involved. It may be 
done manually, using the analog and digital high- 
speed and wideband patch panels in Technical 
Control to accomplish the direct interconnection 
(hardware) of long-haul point-to-point and/or 
local GSFC data channels. It may be accomplished 
semiautomatically via the Digital Matrix Switch 
(DMS), configurations being entered from local 
operator console positions. Or circuit switching 
may be accomplished automatically under the 
Control and Status System (CSS). This definition 
distinguishes circuit switching operations from 
message switching and those switching functions 
performed for trouble isolation, circuit testing, 
and restoration. 

3.2.3 MESSAGE SWITCHING SYSTEM 

The Message Switching System (MSS) is used to 
perform automatic message switching functions 
on wideband, high-speed, and low-speed digital 
data, and on TTY text and data messages. 

3.3 WEST COAST (INTERMEDIATE) SWITCHING 
CENTER 

The following paragraphs describe the West Coast 
Switching Center (WCSC) as an intermediate 
switching facility of the Nascom Network. 

3.3.1 WCSC SYSTEM DESCRIPTION 

3.3.1. 1 WCSC/Nascom Facility Description . JPL 
operates both the GCF-20 communications center 
and the WCSC to support the communications 
requirements of the DSN as part of the Nascom 
Network, respectively. These centers, integral 
parts of the Central Communications Terminal 
(CCT) located in the Space Flight Operations 
Facility (SFOF) building at Pasadena, CA, share 
common equipment. They are separately bud- 
geted and funded by JPL. 

3.3. 1.2 WCSC System Elements . Nascom uses the 
JPL-provided audio switch assembly, which has a 
capacity of 100 external line terminations. The 
758A switchboard provides for switching, con- 
ferencing, and configuring voice and voice/data 
circuits. Nascom-supplied TDM terminals for a 50- 
channel, diversely routed TTY system between JPL 
and GSFC are included in the WCSC. Voice/data 
and TTY technical control and data terminal 
facilities for high-speed and wideband data are 


jointly provided by JPL and Nascom at JPL. This 
equipment is used to through-connect TTY, voice, 
and data circuits from sites in the west coast area 
to GSFC, as well as for local termination, 
distribution, facility control, test, and restoration 
operations. 

3.3. 1.3 JPL/GSOC Interface . In July, 1992 the 
German Space Operations Center (GSOC) located 
in Oberpfaffenhofen, Germany established a 
direct interface with JPL/DSN. To establish this 
interface GSOC leased a 64 kilobits per second 
(kb/s) data circuit and furnished GDC, Inc. 
MiniMux time division multiplexers for use on 
each end. Figure 3-3 depicts the multiplexer and 
circuit configuration. 

3.3.2 NASCOM OPERATING ARRANGEMENTS 

Both the GCF-20 communications center and the 
WCSC are operated 24 hours per day, 7 days per 
week by contractor personnel. The operation of 
both GCF-20 and the WCSC are subject to Nascom 
operating policies, procedures, and guidelines. 

3.3.3 WCSC ENVIRONMENTAL SUPPORT 

FACILITIES 

The environmental support facilities provided for 
the WCSC system include: 

a. Power Facility . Normally, all loads are 
carried on commercial power. Three 1380 kVA 
auto-start diesel generators will assume the load 
within 20 seconds in the event of a commercial 
power failure. During critical mission periods, the 
generators are brought up in a standby mode. In 
the event of failure of both commercial power and 
diesel generators, an Uninterruptable Power 
Supply (UPS) will provide up to 30 minutes of 
power. 

b. Air Conditioning Facility . The air condi- 
tioning system provided for the SFOF has a 1500- 
ton capacity. 

3.4 MARSHALL SPACE FLIGHT CENTER NASCOM 
POINT-OF-PRESENCE 

The following paragraphs describe the Nascom 
Point-of-Presence (POP) at MSFC as an extension of 
the Nascom network. 

3.4.1 MSFC NASCOM POP DESCRIPTION 

3.4.1. 1 MSFC Nascom POP Configuration . The 
Nascom POP facility at MSFC is designed, man- 
aged, operated and maintained by Nascom. The 
Nascom POP is located in room 107, Building 4207, 
MSFC. This facility provides a Nascom interface 
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NOMINAL MUX CHANNEL DISTRIBUTION 
CHANNEL USE 

1 9.6 KB/S FDX 4800-BIT BLOCK A1 ROSAT 

2 9.6 KB/S FDX 1200-BIT BLOCK A7 

3 9.6 KB/S FDX 4800-BIT BLOCK D2 

4 9.6 KB/S FDX 4800-BIT BLOCK 51 SOE/ICV/ODF 

5 VOICE - ROSAT COORD LOOP 

6 VOICE- LORAL 540/01CH»22m 

7 ANTICIPATED TTY CHANNEL 


Figure 3-3. GSOC - JPL MUX Configuration 


and demarcation point at MSFC where individual 
circuits and signals from user facilities may be in- 
terfaced to complex communications systems for 
transport between MSFC and other NASA Centers. 

3.4. 1.2 MSFC Nascom POP Elements . The 
communications systems in the POP consist of 
operations voice circuits, a Nascom 15 megabits 
per second (Mb/s) TDMA terminal, A and B system 
terminals for both JMRTS and KMRTS, ODCS nodes 
A and B, the associated patch panels and the 
interfacing equipment of Nascom's commercial 
carriers. It should be noted that even though 
there are A and B systems for both the JMRTS and 
the KMRTS, the systems are neither identical nor 
redundant. The Nascom MDM replacement 
project is installing MSFC's new MDM hardware in 
the POP thus completing the relocation of 
"Nascom facilities" that have been formerly 
identified for removal from the Huntsville 
Operations Support Center (HOSC). 

NOTE 

There is as yet no project to relocate the 
high data rate system statistical 
multiplexer from the HOSC to the POP; 
should such a project materialize, it is to 
be expected that the existing hardware 
would be replaced with new equipment 
and that the replacement hardware 
would be installed in the POP. This 
would complete removal of “Nascom 
facilities" from the HOSC. Paragraph 


17.4.8 discusses Nascom’s goal for 
replacement of the HDRS. 

Figure 3-4 depicts the floor plan of the Nascom 
POP as of January 1 994. 

3.4.2 NASCOM OPERATING ARRANGEMENTS 

A preliminary Memorandum of Understanding 
(MOU) for Nascom POP at MSFC has been written 
and is in the review and signature cycle. This 
MOU, executed between Nascom (GSFC/540) and 
the Information Systems Office (MSFC/AI01), sets 
forth the following: 

a. The MOU formally codifies accommoda- 
tions and arrangements previously agreed upon. 
It defines major areas of responsibility for Nascom 
and for MSFC. 

b. The Nascom POP is staffed by Nascom 
and reports operationally to the Communications 
Manager at Nascom, GSFC. Nascom provides 
specifications for hardware installation and 
determines requirements for the facility. Nascom 
provides operating and maintenance personnel 
sufficient to staff the facility on a single shift basis 
five days a week. This staff is also required to 
provide coverage on an extended basis as 
operational mission requirements may dictate. 
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SECTION 5 

MAJOR GROUND COMMUNICATION SUPPORT SYSTEMS 


5.1 GENERAL 

This section describes the Nascom systems that are 
considered vital to the operation of the Nascom 
Network. These systems are within the scope of a 
major ground communication support system as 
defined in paragraph 4.1. They are introduced in 
the early part of this document to provide the 
reader an understanding of what they are first, 
and what they become as part of an integral or 
whole system. 

5.2 VOICE SWITCHING SYSTEM (VSS) 

5.2.1 SYSTEM DESCRIPTION 

The VSS is a totally electronic digital switching sys- 
tem. The VSS currently has the capability to 
switch, conference, and monitor 2000 analog 
lines/circuits. The VSS is equipped to terminate 10 
two-wire dial lines and 1990 four-wire private-line, 
long-haul or local circuits with manual 
"ringdown" signaling. The two-wire lines are in- 
corporated into the system to provide emergency 
dial-up service in the event of four-wire private 
line failures. Two-wire dial-up services are not a 
standard offering for Nascom operational voice 
conferences. Conferencing capability is limited 
only by the number of circuits configured to the 
system. The system hardware design is modular 
thus enabling expansion to support future user re- 
quirements. 

The VSS provides point-to-point and/or 
conference voice communications for project and 
operations support on a network of high-quality 
local and long-haul voice and voice/data circuits. 
The circuits radiate to the Nascom users either 
directly or through a Nascom remote switching 
center. Figure 7-1 shows the communications 
environment in which the VSS operates. [Note: 
Use of the term “SCAMA" is now limited to denote 
tail (local loop) circuits between the VSS and the 
POCCs located on Goddard Space Flight Center; 
any other use of the term is outmoded and 
discouraged.] 

5.2.2 SYSTEM INTERFACES 

The VSS is the focal interface for voice and 
voice/data circuits coming from the following: 

a. Local GSFC facilities. 

b. Domestic NASA switching center. 


c. JSC Mission Control Center. 

d. Overseas Network Stations. 

e. KSC facilities and other U.S. terminals. 

5.3 DIGITAL MATRIX SWITCH 

This paragraph provides a standalone description 
of the DMS. Its role as a major support system of 
the BDS for SN is described in Section 1 1 . 

5.3.1 DMS DEFINITION 

The DMS, located at GSFC, is a three-stage, solid- 
state circuit switch composed of a forward matrix 
and backup, return matrix and backup, and a con- 
trol subsystem. The function of the DMS in the SN 
is to route TDRSS/NGT and JSC MDM traffic flows 
to/from users of the SN via GSFC. The DMS, when 
used as a generic system, can be defined as a 
computer-driven system that provides a circuit 
switching capability for the Nascom Network. 

5.3.2 DMS SYSTEM DESCRIPTION 

5.3.2. 1 Brief Profile of DMS . The DMS was built 
by Applied Physics Laboratory (APL) of Johns Hop- 
kins University. In August 1989 the PDP 11/03 was 
replaced by DEC MicroVAX II computers, which can 
be controlled by the CSS or an operator. The CSS 
at GSFC automatically controls and monitors the 
status of the DMS in accordance with the NCC 
schedule. Except for the computer terminals and 
printer, the DMS hardware is housed in nine racks. 

5.3.2.2 DMS Configuration . A block diagram of 
the DMS is shown in Figure 5-1. The DMS is confi- 
gured to employ full switching redundancy, where 
four switching systems (two forward and two re- 
verse) utilize redundant power systems tied to “A" 
no break and “B" no break power grids. 

5.3.2.3 System Elements . The DMS consists of cir- 
cuit switches and a Digital Matrix Switch Control 
System (DCS). The DMS system consists of the fol- 
lowing elements: 

a. DCS hardware . The operational configu- 
ration is comprised of two systems, prime and 
backup. Each system consists of the following 
components; 1 DEC MicroVAX II CPU, 1 DEC Win- 
chester disk, 1 DEC terminal, 1 DEC magnetic tape, 
and an AT&T printer. 
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Figure 5-1. System Block Diagram of the Digital Matrix Switch 


b. DCS software consisting of the DEC VMS 
Operating System and application software devel- 
oped by Science Systems and Applications, Inc. 
(SSAI), and CSC in FORTRAN language. 

c. DMS system controller based on a T-bar 
relay system panel featuring or using illuminated 
push-button switches. 

d. Two input and two output buffers, 
where each buffer features a 192-port capability 
using an RS-422 interface. 


e. Two forward and two return 3-stage 
switch matrices, where each switch matrix is ca- 
pable of handling 192 input and 192 output lines. 

f. A DMS patchfield to physically interface 
the Nascom Network and GSFC users with the 
DMS. 

5.3.2.4 System Interfaces . The DMS was de- 
signed to provide the interface between the SN 
Type 1 forward return link services and local and 
remote POCC's. 
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5.3.3 SYSTEM OPERATION 

5.3.3.1 DMS Data Flow . As indicated in Figure 
5-1, all data flow through DMS is referenced to the 
GSFC users forward link as data-out from the user. 
The network return link is data-in from the net- 
work to the user. The data flow through the ma- 
trix switch is described in the following para- 
graphs: 

a. DMS System Controller . This controller 
provides the mechanism for centralized control 
and configuration of the DMS. It operates through 
the T-bar relay system panel consisting of illumi- 
nated pushbutton switches. The online systems 
can be selected from this controller panel, where 
the select and control pushbuttons for the forward 
and return matrix switch arrays, associated output 
buffers, DEC MicroVAX computers, and the VT-220 
terminals are featured. The controllers can also al- 
low reconfiguration in the event of a system com- 
ponent failure or for normal maintenance and 
testing. 

b. Matrix Switch Signal Flow . The matrix 

switch design employs a 3-stage switch array based 
on the theory developed by Charles Clos. A non- 
blocking design, which reduces the number of 
switch crosspoints from that of an X-Y equivalent 
array, was implemented. The switching algorithm 
follows the crosspoint equation: Number of 

crosspoints = 6(N exp(3/2))-3N, and with N =192, 
the number of crosspoints = 15,387. The matrix 
switch arrays, consisting of the A-array, B-array, 
and C-array, are controlled via an IEEE-488 General 
Purpose Interface Board (GPIB). The computer is 
used to determine the path through the switch for 
a given input/output connection. 

c. Ancillary Device Function . The Baseline 
Data System uses the DMS as an ancillary device to 
support the SN. MDM channels are terminated at 
the DMS. MDM channels that are scheduled to 
support the SN are configured by commands from 
the CSS or by technical control personnel using 
keyboard entries to make DMS Input/Output con- 
nections. 

5.3.3.2 DMS Circuit Switching and Control . The 
DMS acts as the heart of the SN/Nascom Network 
for circuit switching. Network and user channels 
of the BDS are connected by the DMS. NCC sched- 
ule requests to Nascom are satisfied by circuit 
switching the network and user channels for for- 
warding and returning data through the DMS. Fig- 
ure 5-2 depicts the Nascom Digital Matrix Switch- 
ing System and Controls. Figure 5-3 depicts the 
DCS hardware configuration. 


a. Return Link-DMS . The DMS for the re- 
turn link has 192 input ports and 192 output ports. 
The switch is controlled by a MicroVAX II. Any in- 
put port from the network channels can be 
switched to any ten output ports (top user chan- 
nels) for interfacing return link services to users. 
The first 100 input ports of the return link DMS re- 
presents the SN-Baseline Data Channels. The 
source channel identification number of the SN- 
service channel is used to identify the port to be 
switched. The output ports of the return link DMS 
are used to terminate users of the SN-BDS service 
channels and become the destination channel ID 
for data transferred to them. 

b. Forward Link-DMS . The forward link 
DMS is identical to the return link DMS with 192 in- 
put and 192 output ports and a MicroVAX II as the 
controller. User source channels are connected to 
the input ports of the DMS. SN destination chan- 
nels are connected to the output ports. The first 36 
ports represent the SN destination channels in the 
forward link. 

5.4 MESSAGE SWITCHING SYSTEM UPGRADE 

This paragraph provides a standalone description 
of the MSU. Its role as a major support system of 
the other Nascom and NASA Network systems is 
described in later sections. 

5.4.1 SYSTEM DEFINITION 

Message switching is the general classification of a 
data driven, connectionless oriented switching sys- 
tem in which the destination address(es) of a given 
message are included as a portion (normally the 
leading characters or headers) of the message it- 
self. The system handles data and message traffic 
through a switching center, either from local users 
or from other switching centers. Message switch- 
ing operates in one of two ways: either a virtual 
real-time data path is established between the 
transmitting and receiving stations, or the 
message-type traffic is stored and forwarded 
through the system. 

5.4.2 SYSTEM DESCRIPTION 

5.4.2. 1 Brief Profile of MSU . The Message 
Switching System (MSS) was established by 
Nascom early in the NASA program, to support the 
ground tracking networks long before the SN 
came into being. Nascom developed the MSS into 
a facility complex of communications processors 
and associated equipment (located at the GSFC 
primary Nascom switching center) to perform 
automatic message switching functions for the 
TTY, high-speed data, and wideband data systems. 
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Figure 5-2. Nascom Digital Matrix Switching System and Controls 
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Figure 5-3. DCS Hardware Configuration 
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The hub of this complex was a dual complement of 
redundant computer systems, that were Nascom- 
designed, -implemented, and -programmed to 
provide a data-driven automatic switching func- 
tion. The computer performed network traffic 
control functions in addition to its primary func- 
tion of message switching data between the 
Nascom Network users. The MSS handled 4800 bit 
fixed format data block interchanges between us- 
ers on high-speed and wideband data lines. It also 
handled variable sized text and fixed format data 
necessary on TTY and low-speed data lines. At 
more than 10 years old, the MSS equipment out- 
lived its specified life expectancy. Since several 
items were special-engineered, one-of-a-kind 
communication peripherals, the performance of 
maintenance was restricted to only the few field 
engineers and the design engineer who had built 
them. Furthermore, age and increased demands 
on the system for more line terminations and over- 
all higher line rates pushed the total throughput 
of the system past original limits. All these condi- 
tions contributed to the resultant decrease in 
MeanTime-Between-Failures (MTBF), increase in 
Mean-Time-To-Restore (MTTR), and an unaccept- 
able restriction on those engineers responsible for 
equipment maintenance. The MSS Upgrade (MSU) 
project, initiated in 1989, was developed in order 
to rectify this situation. All three front-end units 
per MSS system (6 total) have been replaced with a 
single communications peripheral per system. Re- 
placement included terminating ail currently sup- 
ported circuits, providing all presently supported 
high-speed functions, and yet still allowing future 
circuit terminations (expansion) and increased 
functionality (requirements). The Combined Op- 
erator Workstation (COW) was designed as the sin- 
gle point of control and operator interface for 
each of the switching computers. The system will 
be referred to as the Message Switching System 
Upgrade (MSU) until the completion of all 
planned upgrades, at which time the system name 
will revert to simply Message Switching System 
(MSS). 

5.4.2.2 MSU Configuration . Since the MSU is a 
computer-driven system, the discussion of its con- 
figuration will include the hardware and the soft- 
ware elements. The hardware components are 
grouped into two separate but functionally iden- 
tical systems. The MSU software is configured 
from the vendor-supplied system software, and 
from the in-house or Nascom developed software, 
commonly referred to as the applications soft- 
ware. 

5.4.2.3 MSU Hardware Elements . The cluster of 
equipment for each group consists of the follow- 
ing elements: 


a. MSU Switching Computer . The MSU 
switching computer hardware is a Concurrent 
Computer Corporation Series Micro 3200 Ex- 
panded System (Micro 5 ES). The system is en- 
hanced by the addition of an integrated, 
highperformance, intelligent serial input/output 
(I/O) communications control system (ComPlus) 
supplied by Kardios Systems Corporation. The 
ComPlus system interfaces with the Concurrent 
host processor via direct memory access (DMA). 
The ComPlus supports dynamic port reconfigura- 
tion, and is programmed to the communication- 
line level to identify the 24-bit Nascom block syn- 
chronization code. The ComPlus supports the re- 
ception of bit-contiguous blocks with no idle time 
and buffers each Nascom 4800-bit block to the ex- 
tent necessary to complete the application soft- 
ware processing of the block. Seven ComPlus port 
cluster units are configured with the Concurrent 
machine. Each cluster unit supports 32 ports for a 
total of 224 ports for each MSU Switching Com- 
puter. Additional MSU peripheral devices include 
a line printer, a system console, a mass-storage 
disk system, two cartridge tape units, and a 
ninetracktape unit. 

b. COW . The COW hardware is a SUN 
SPARCstation II that uses reduced instruction set 
(RISC) technology. The COW peripheral devices in- 
clude a laser printer, a high-resolution color moni- 
tor, a mass-storage disk system, and CD-ROM unit, 
serial ports, and a cartridge tape unit. 

c. X Terminals . The X terminal hardware is 
a nineteen inch color Tektronics XP337 with nine 
megabytes of memory and a trackball pointing de- 
vice. The XP337 is capable of displaying 256 colors 
simultaneously and running both X windows and 
the Motif window manager locally. There is one X 
terminal associated with each COW. The X termi- 
nal supports some of the COW screen displays. 

d. Hybrid PC . The hybrid PC hardware is an 
IBM PC compatible 80486 running at 33 Mhz. The 
hybrid PC provides a gateway between the TCP/IP 
LAN and the Nascom high-speed network. The PC 
includes 3Com network boards which provide the 
interface to the TCP/IP LAN. Nascom boards, de- 
veloped by NASA, provide the interface to the 
high-speed network. The hybrid PC utilizes the 
UNIX operating system. 

e. MSU Command LAN . An Ethernet LAN 
provides Institute of Electrical and Electronic En- 
gineers (IEEE) 802.3 physical interface connections 
between all of the MSU and COW system. The two 
MSU and COW systems are configured on a single 
LAN trunk. This LAN trunk is comprised of two 
parallel LAN rails which are used as primary and 
backup LANs. By changing the machine plugs into 
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the LAN, the operator can isolate a single machine 
or machine group on the backup LAN rail. 

5.4.2.4 MSU Software Elements . Software for 
the MSU is best addressed in two categories: MSU 
system software, and COW software. The compo- 
nents for each category are delineated in the fol- 
lowing paragraphs: 

a. MSU System Software. 

1. Vendor Software. 

(a) OS/32 - Concurrent Computer Cor- 
poration multi-tasking real-time operating system. 

(b) Utility and support programs. 

(c) Editor programs. 

2. Application Software. 

(a) MBI - MSU backup operator inter- 
face task. 

(b) MCMD - MSU console command 

task. 

(c) MCU - MSU/COW common utility 

modules. 

(d) MDD - MSU database distribution 

task. 

(e) MDS - MSU data simulator task. 

(f) MHL - MSU high-speed logging 

task. 

(g) MHS - MSU high-speed switching 

task. 

(h) MHU - MSU high-speed utility task. 

(i) MHY - MSU hybrid data task. 

(j) MIF - MSU/COW interface task. 

(k) MIN - MSU initialization and recov- 
ery task. 

(l) MMG - MSU message generator 

debug tool. 

(m) MSU - MSU tools and utilities. 

(n) MU - MSU common units. 

(o) MUDUMP- MSU task dump utility. 

b. COW Software. 

1. Vendor Software. 


(a) OS 4.1.3 - SUN SPARCstation oper- 
ating system. 

(b) Utility and support programs. 

(1) X-Window 

(2) Transportable Application En- 
vironment Plus (TAE Plus) 

(3) Motif window manager 

(4) C Language Integrated Produc- 
tion System (CLIPS) 

(c) Editor programs. 

2. Application Software. 

(a) BOOTMSU - warm start of the MSU 
applications from the COW 

(b) CAL -COW alert processing task 

(c) CCM - COW baseline configuration 
change task 

(d) CCQ - COW command and query 

task 

(e) CDB- COW database manager task 

(f) CDL- COW delogging task. 

(g) CES - COW expert system task. 

(h) CHC - COW checkpoint configura- 
tion change task 

(i) CIF - COW- MSU interface task 

(j) CIN - COW initialization and recov- 
ery task 

(k) CLD - COW line indicator display 

task 

(l) CLG -COW logging task 

(m) CMG - COW message generator 

debug tool 

(n) COA - COW operator assistance 

task 

(o) CONVTXT - converts ASCII text files 

(p) COS - COW operator stations task 

(q) CTS- COW troubleshooting task 

(r) CU - COW common units 
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(s) STARTCOW - warm start of the 
COW applications 

5.4.2.S System Interfaces . The MSU interfaces 
with the high-speed data and wideband network 
users. The principal user MSU interfaces are for 
GN-related operations. The users are required to 
generate compatible high-speed and wideband 
data message switching format. When the 
Nascom 4800-bit block format is used, the 48-bit 
network header is utilized for routing high-speed 
data. 

5.4.3 SYSTEM OPERATION 

5.4.3.1 Overview of MSU Operations . Two com- 
plete MSU hardware systems are configured to 
provide an online operational system and an 
offline hot-spare system. The hardware systems 
are designated as either the A or the B system; 
thus there is an MSU-A, an MSU-B, a COW-A and a 
COW-B. The two X terminals are designated as 
XTERM-A and XTERM-B. The systems communi- 
cate with each other across the LAN. Figure 5-4 il- 
lustrates the configuration of the MSU. Input 
from the network is sent to both systems. Output 
to the network is selected by the transfer switch. 
The transfer switch allows operations to select the 
online MSU. The output of the online MSU is sent 
to the network; the output of the offline MSU is 
discarded. The MSU switching computer and COW 
each perform a subset of the MSU functions as de- 
scribed in the following paragraphs. 

a. The MSU switching computer is primarily 
responsible for switching the 4800-bit Nascom 


blocks. Other functions of the MSU switching 
computer include collecting historical archives of 
high-speed network activity, managing the high 
speed network configuration, interfacing with the 
operator workstation, and providing a backup op- 
erator interface. 

b. The COW computer is the primary means 
of access for the MSU operator. It supports opera- 
tor interfaces to display the network status and to 
change the network configuration. 

The two online MSU computer systems are oper- 
ated from no-break power. The no-break systems 
normally take power from the commercial feed, 
but have the capability to be transferred to local 
diesel power in case of loss of commercial service. 
The transfer to battery power is automatic. The 
diesel transfer can be automatic or manual. 
Where it is critical that hardware, such as disk 
memory, be protected from power spikes, peaks, 
and surges, their electric power circuits are buff- 
ered by means of motor-alternators. These motor- 
alternators are normally powered from the com- 
mercial source with diesel capability existing via 
the transfer switches. 

5.4.3.2 MSU Communication Format . Users are 
required to generate a compatible high-speed and 
wideband data message switching format for use 
with the high-speed MSU. Appendix D describes 
the 4800-bit block structure which is the basic 
Nascom high-speed and wideband data message 
switching format. This format is generated by the 
GN and by all users of the system. 
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Based on the current field size for source and des- 
tination codes in the Nascom 4800-bit block, all 
256 MSU source and destination codes have been 
exhausted. In order to expand the number of valid 
source and destination codes from 256 codes to 
512 codes, the sequence monitoring field is being 
eliminated from the Nascom 4800-bit block. The 
sequence monitoring bits, which currently identify 
the sequence of block transmission, are bits 41-43 
of the Nascom network header. The following 
changes will be implemented for these bits: 

Bit 41 - destination code expansion (this aligns 
with the current destination code bits 33 
to 40) 

Bit 42 - source code expansion (currently the 
source code occupies bits 25 to 32) 

Bit 43 - spare 

For both source and destination codes, a value of 
zero (0) in the new bit would use the current rout- 
ing codes of 0 to 255. A value of one (1) would use 
routing codes 256 to 511. 

The changes are currently scheduled for imple- 
mentation in March 1995. 

5.5 DATA DISTRIBUTION AND COMMAND SYS- 
TEM (PDCS) 

The DDCS derives its name from its original im- 
plementation role in supporting the packet 
switching requirements of the GRO project, as a 
dedicated system which is described in paragraph 
16.2.7. The DDCS is intended, however, to be an 
institutional X.25 packet switching system for 
operational traffic requirements of Nascom users. 
The institutional, shared network resource nature 
of DDCS is demonstrated by its use in support of 
the EUVE and SAMPEX projects. 

5.5.1 SYSTEM DEFINITION 

The DDCS, as defined in Nascom Document No. 
541-008, DDCS System and Functional Require- 
ments, is the system which will provide the packet 
switching communications, via the X.25 protocol, 
to satisfy the command request, data base ex- 
change requirements, and telemetry distribution 
for the various projects' principal scientific inves- 
tigators. The X.25 protocol is an international, 
standardized data communications protocol 
which specifies the interface between DTE and 
DCE for terminals operating in the packet mode. 


5.5.2 SYSTEM DESCRIPTION 

5.5.2. 1 Brief Profile of DDCS . The DDCS will gen- 
erally support ground data communications be- 
tween the scientific experimenters whose instru- 
ments are aboard certain spacecraft, the ground 
support equipment at the experimenters location, 
and other GSFC systems necessary for operational 
support of the satellite experimenters operations 
and data distributions. These other systems and 
their roles are as follows: the Packet Processor 
(PACOR)/Code 560, which processes the telemetry 
data packets that are shipped to the experiment- 
ers; and the Command Management System 
(CMS)/Code 510, which receives and validates in- 
strument command data from the experimenters; 
and the spacecraft contractors System Test Com- 
plex (STQ facility, which simulates the functions of 
the PACOR and the CMS for prelaunch integration, 
testing, and support. These are the end systems 
which presently use the DDCS packet switching 
network. 

5. 5.2.2 DDCS X.25 Configuration . The DDCS 
Packet Switching Network (PSN) consists of two 
main PSN's, located at GSFC Building 14, which in- 
clude online and backup support for up to 40 
trunks or X.25 subscriber ports, and switches up to 
300 packets per second per PSN. Two remote PSN's 
are trunked to the main PSN's (see Figure 5-5). 

5.5.2. 3 System Elements 

a. GSFC PSN's . The configuration of the 
GSFC PSN's consists of two AMNET Nucleus 7400 
Network Management Processor (NMP) nodes, 
each with a hot backup. The AMNET N7400 is a 
mid-range performance packet switching system 
based on Line Processor (LP) boards using 80186 
microprocessor chips. These LP's exist in an ex- 
tended chassis with the 80386-based CPU. The 
N7400 contains a 1.2 MB floppy disk drive with a 
high density disk controller. The PSN is booted off 
the Disk Operating System (DOS) floppy disk con- 
taining AMNET software. Automatic failover 
switching occurs between node/primary and back- 
up nodes through the HADAX switch/control unit. 
All user ports are connected through the HADAX. 
Through patching at the Nascom Technical Con- 
trol area, an X.25 protocol analyzer can be used 
for circuit data monitoring. GRO and SAMPEX us- 
ers are connected to Node 1; EUVE users are con- 
nected to Node 2. 

b. NMP's . Two NMP's function as the oper- 
ator control and status interface, providing a 
graphics display for troubleshooting, and manage 
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Figure 5-5. DDCS Network Configuration 


the operational network database. NMP 1 is con- 
nected to Node 1 , and NMP 2 is connected to Node 
2 at the GSFC. The NMP is currently based on 
80386 IBM Personal Computer Advanced Technol- 
ogy (PC/AT) hardware with a 100 MB hard disk. 
The NMP stores system software files for initial 
program load and selective program load. These 
software files have been programmed using the 
high-level "C" language, which is used under the 
UNIX operating system. The NMP is connected to 
the respective node through an AMNET custom- 
designed Primary Interface Adapter (PIA) cable 
and computer board. 

c. Remote PSN's . The remote PSN's are 
located at MSFC in Huntsville, Alabama, and the 
University of California, Berkeley Campus. These 
remote PSN's are N7400 Packet Processor Modules 
(PPM) nodes, and do not have local NMP's 
attached. They communicate with the GSFC NMP's 


via the trunks. Each site has an N7400 PPM with a 
redundant backup node. HADAX automated 
failover units exist at each site. Each N7400 
consists of an 80286 PC/AT compatible unit, 640K 
Random Access Memory (RAM) and a 1.2 MB 
floppy drive with high density disk controller. The 
nodes boot off of DOS system formatted floppies, 
with node boot floppy software downloaded from 
the GSFC NMP's. Each remote PSN contains two LP 
boards with 80186 microprocessors. Node 3, which 
supports GRO, and Node 4, which supports EUVE, 
are currently operational. 

5.5.3 SYSTEM OPERATION 

The DDCS Network was accepted by Nascom oper- 
ations on 17 May 1990. DDCS operations are de- 
scribed in the following paragraphs. 
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5.5.3.1 DDCS System Capabilities . The DDCS pro- 
vides the following capabilities: 

a. Packet switching communications be- 
tween the Principal Investigators Instrument 
Ground Support Equipments (IGSE), CMS, STC, and 
PACOR. 

b. Monitoring the status of the network, 
and communication links. 

c. Logging/delogging all alarms, status, and 
changes in the system configuration. 

d. Operations from a local interactive termi- 
nal. 

e. Printing information on traffic data and 
usage. 

5.5.3.2 Details on Provision for X.25 Packet 
Switching Capability . The DDCS provides an X.25 
packet switching (CCITT 1984 Recommendation) 
capability to distribute the packetized scientific 
data for the spacecraft missions and packetized 
command requests between the IGSE's, CMS, ex- 
perimenter homesites, STC, and PACOR. The CCITT 
X.25 specified system supports the first three levels 
of the International Standard Organization (ISO) 
Open System Interconnection (OSI) architecture. 
The DDCS as a DCE was developed to interface the 
external equipment or DTE at the following levels: 

a. Physical layer (Level 1) . The required 
characteristics are as follows: 

(1) Interface . The physical, electrical, and 
functional characteristics to establish, maintain, 
and disconnect the physical link between the DTE 
and the DCE shall conform to the Federal Standard 
1020, EIA RS-422, and EIA RS-232C. 

(2) Transmission rate . The DDCS supports 
9.6, 56, 64 and 224 kb/s transmission rates be- 
tween the DCE and DTE. 

b. Link Laver (Level 2) . The DDCS supports 
the LAPS procedure and all parameters specified 
by the users of each project. 

c. Network Laver (Level 3) . The DDCS sup- 
ports the following communication features: 

(1) Services: Virtual call and permanent 
virtual circuit. 

(2) Packet types: All basic packets speci- 
fied in CCITT X.25, 1984 Recommendation. 


(3) User data field length: Maximum of 
1 024 octets/packet. 

(4) Packet sequence numbering: 

Modulo 8. 

(5) Frame sequence numbering: Modulo 8 
and Modulo 128. 

(6) X.25 Diagnostic code: Standard. 

5.6 MDMR DATA SYSTEM 

This paragraph provides a standalone description 
of the MDMR Data System. Its role as a major ele- 
ment of the BDS is described in Section 11. 

5.6.1 SYSTEM DEFINITION 

The MDMR Data System, when referred to as an 
integral part of the BDS, can be defined as a sys- 
tem featuring the following characteristics: 

a. Two online full duplex terminals at each 
location: NGT, GSFC, and JSC. 

b. Functionally consists of separate MDMR 
data terminal controlled by a collocated Multiplex- 
er/Demultiplexer Automatic Control System Up- 
grade (MACSU) at each location. (The MACSU was 
developed as a separated project to upgrade the 
MACS in support of the MDMR Data System. See 
Paragraph 5.6.5 for more information on the 
MACSU.) 

c. MDMR line interface channels designed 
for data rates between 10 b/s and 7 Mb/s. 

d. A composite (common carrier interface) 
transmission rate capability of up to 20 Mb/s. (This 
is an upgrade from the original MDM Data System 
capability.) 

e. Range of data format capabilities and op- 
erating features available as options to the users. 

5.6.2 SYSTEM DESCRIPTION 

5.6.2. 1 Brief Profile of the MDMR Data System . 
The Nascom Network extends the TDRSS forward 
link and return link services by providing data 
transport systems between the NASA Ground Ter- 
minal at White Sands, NM; the NCC; and major us- 
er spacecraft control centers and data processing 
facilities. Both the TDRSS and Nascom Network 
are elements of the SN. Nascom has implemented 
two distinct multichannel transport systems to ex- 
tend the TDRSS data transmission. One of these is 
the BDS which supports the Type I interfaces 
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(10 b/s to 2 Mb/s). An essential component of BDS 
is the MDMR Data System. An MDMR terminal is 
installed at MSFC to serve as the tandem link to 
GSFC, where NGT forward and return link SN user 
services are extended to MSFC. The Nascom re- 
placement MDM Data System specification docu- 
ment (541-89-03) was developed in the early 
1990's in accordance with the Project Manage- 
ment Plan (541-097). Installation of the MDMR 
was completed in late 1993. 

5.6.2.2 MDMR Data System Configuration . 
Figure 5-6 illustrates the MDMR data flow block 
diagrams. The system configuration of the 
baseline MDMR data subsystem is shown in Figure 
5-7. The MDMR data subsystem consists of 
separate data terminals at GSFC, NGT, and JSC. 
Operationally, the baseline MDM system had the 
capability of 100 return link channels from NGT to 
GSFC, and 36 forward link channels from GSFC to 
NGT. The JSC station in the baseline MDM system 
was operationally considered as a drop and insert 
station. JSC could insert up to 30 channels into the 
forward link and up to 20 channels into the return 
link to/from NGT and GSFC. When this occurred, 
the total number of channels available for 
scheduling between NGT and GSFC was reduced 
by an equivalent number. The MUX/DEMUX 
systems and channel capacities provided by the 
MDMR Data System at the respective locations are 
as follows: 


a. GSFC: 

MUX (Broadcast) 

48 channels 

DEMUX (NGT/STGT) 

128 channels 

DEMUX (JSC) 

48 channels 

b. JSC: 

MUX (Broadcast) 

48 channels 

DEMUX (GSFC) 

48 channels 

DEMUX (NGT) 

48 channels 

c. GSFC/MSFC Trunk: 

MUX/DEMUX 

24 channels 
(duplex) 


The above channelization represents an upgrade 
to the original MDM Data System capabilities. All 
indicated MUX/DEMUX equipment will be pro- 
vided in redundancy. Connectivity is the same as 
per the original MDM Data System, except that 
spare DEMUX equipment lacking in the original 
MDM Data System has been added for each 
downlink at each location; also a connectivity 
change has been implemented at the GSFC loca- 
tion wherein all receive channels from WSGT and 
JSC have been extended to the DMS in lieu of a 
channel termination sharing arrangement. 


5.6.2.3 System Elements . As indicated in Figure 
5-6, the MDMR functional elements are as follows: 

a. Interface equipment that includes patch 
panels, signal splitters, and channel select switch- 
es. 

b. Multiplexer that includes Input Terminal 
Units (ITU) and Output Controller (OC). 

c. Demultiplexer that includes Input Con- 
troller (1C) and Output Terminal Units (OTU). 

d. MACSU that include Control Subsystem 
Transfer Switch (CSTS) computer system. 

e. Local operator control console that pro- 
vides manual configuration capability at individual 
ITU /OTU control panel. 

f. Effective with the MDMR Data System, 
MDM control is entirely remoted to consoles (no 
front panel controls) and channel Port address is 
now remotely controllable. 

5.6.2.4 System Interfaces . The system interfaces 
of the MDMR Data System are as follows: 

a. At NGT, the MDMR interfaces with the 
TDRSS forward and return link user services. 

b. At GSFC, the MDMR interfaces with the 
NCC via the CSS and with the SN users. 

c. At JSC and MSFC, the MDMR interfaces 
with the SN users. 

5.6.3 MDMR OPTIONS AND FEATURES 

MDMR Data Systems users can select data process- 
ing options by specifying the options in con- 
figuration codes developed during mission plan- 
ning and by including their options in their sched- 
uling requests to the NCC. The MDMR Control Sys- 
tems configure the MDMR in accordance with the 
user's scheduled request to the NCC. The follow- 
ing processing options and operating features are 
available to the users, and are described below: 

5.6.3. 1 Unblocked or Blocked Data . The user 
chooses to supply/receive data in either unblocked 
or blocked format. Unblocked data is defined as a 
serial bit-contiguous data stream with no header 
or routing information. When unblocked data is 
supplied, it is inserted in the data field of an 
MDMR Data System-generated 4800-bit data 
block, along with appropriate system-generated 
network header information and a polynomial 
code per data block. Users who elect to receive 
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Figure 5-7. Configuration of the MDMR Data Subsystem in the 

Baseline Data System 


unblocked data receive a serial stream of data 
from the data field of the block, after the system 
strips out the network header, user header, time 
block, and the block error control field. 

Blocked data is defined as data that is supplied/ re- 
ceived in a 4800-bit block format, and that con- 
tains a network header, user header, time tag, and 
a block error control field. The user may insert the 
time tag. 

If a user is remotely located from the MDMR and 
requires long-haul circuit facilities, Nascom can be 
consulted to determine the technical feasibility 
and cost effectiveness of selecting the unblocked 
serial data option. At rates above 1800 b/s, special 
payload block formatting equipment may be avail- 
able from Nascom on a loan or reimbursable basis. 

5. 6.3. 2 Selectable Data Rate . MDMR Data Sys- 
tem users may choose supplying or receiving 
blocked or unblocked data at rates from 10 b/s to 
7 Mb/s. The data rate selected must be approved 
by Nascom personnel due to the bandwidth limita- 
tions of the Common Carrier Broadcast Trans- 
mission Service (CCBTS) and the multiple user 
network channels serviced by the MDMR Data Sys- 
tems. The exact data rate specified is selected by 


setting the most significant decimal digits and a 
single decimal digit exponent of the associated 
clock. In addition, when receiving blocked data, 
the option of supplying the clock externally or us- 
ing the internal MDMR Data Systems clock exists. 

5.6. 3. 3 Unmodified or Modified Network Head- 
er. This option is available only to users supplying 
data in a blocked data format. The MDMR Data 
System user may choose to have an unmodified or 
modified network header. If the user chooses the 
unmodified network header, the user inserts the 
network header information into the MDMR Data 
System, and the system transmits the 4800-bit 
block exactly as inserted by the user. If the user 
chooses the modified network header, the MDMR 
Data System will modify the network header by in- 
serting a selected data stream ID and a sequential 
port sequence number. The MDMR Data System 
will also generate a new polynomial code at the 
end of the 4800-bit block. 

5. 6. 3.4 Time Tagging . The time-tag option is 
available only when a user is transmitting blocked 
data to an MDMR Data System. When requested 
by a user, the time-tag option enables an MDMR 
Data System to write the time of year into the time 
field of the 4800-bit data block. The time of year is 
provided in the NASA PB-4 time format. (See 


GROUND COMMUNICATION 5-13 




540-030 

FY94-2 


Figure 5-8.) This time is referenced to the time the 
MDMR Data System detects the last bit of the 
network header synchronization pattern. A new 
polycode is generated and inserted in each data 
block that is processed under the time-tag option. 
If the time-tag option is not selected, the MDMR 
Data System transmits the 4800-bit data block with 
the time field exactly as received. The GSFC system 
inserts a static pattern in the time-tag field when 
the time-tag option is not selected. 

5.6.3.5 One-second Timeout . The one-second 
timeout option is useful to a user supplying 
unblocked data to an MDMR Data System at a low 
bit rate. The unblocked data is inserted into the 
data field of an MDMR Data System generated 
4800-bit data block. With the timeout option 
selected, if the input data rate is such that the full 
block of 4624 data bits is not received in one 
second, the MDMR Data System will timeout, 
complete the data field with fill bits, generate a 
polynomial code, transmit the data block, and 
begin building a new data block. The timeout of 
the data block occurs only at the boundaries of 
8-bit bytes as measured from the first bit inserted 
in the data field of the data block. 

If the timeout option is not selected, the MDMR 
Data System continues to accumulate the incom- 
ing data and generate circuit assurance blocks at 
the rate of one per second until a full data field of 
incoming data is entered in the data block. 

5.6.3.6 Circuit Assurance Blocks . This option is 
available only to users receiving blocked data. If 
the input data rate is such that the source MDMR 
Data System does not have a data block ready for 
transmission within one second, the source MDMR 
Data System generates and transmits Circuit Assur- 
ance Blocks (CAB) to the destination MDMR Data 
System at a one block-per-second rate. The CAB's 
are generated in the same data format as the 
Nascom/TDRSS 4800-bit block, but are uniquely 


identified (by setting the data length field to zero 
and filling the data field with a 11001001 bit pat- 
tern) to distinguish CAB's from data blocks. 

The CAB's are generated for use within the MDMR 
Data System. When a user specifies the CAB op- 
tion, the operation of the MDMR is not altered, 
but merely enables the user to receive the CAB's 
whenever they are generated. The CAB's provide 
the user with a confidence check on circuit oper- 
ations. 

5.6.3.7 Undamped or Clamped Clock . The des- 
tination MDMR/OTU delivering unblocked data 
has the option to deliver an unclamped clock or 
clamped clock signal to the user interface. With 
the undamped clock option, the destination user 
interface receives a continuous clock signal at the 
selected rate. The clock signal is uninterrupted as 
long as the user's channel is enabled, regardless of 
whether data is being processed or not. When the 
user selects the clamped clock option, the destina- 
tion interface receives data and clock signals at the 
selected rate. During those periods when no data 
is being processed (OTU buffers depleted), the 
clock signal is clamped to a logic 1. When the next 
data block is available for transmission to the user, 
the clock signal resumes in synchronization with 
the data. 

5.6.3.8 Clock Tracking . The clock tracking option 
is available when the destination MDMR Data Sys- 
tem is supplying unblocked (serial bit contiguous) 
data to the user. This option prevents the data 
overflow/underflow condition that occurs from 
the inevitable variations between input clock and 
output clock frequencies, even when operated 
within specified tolerances. Data overflow occurs 
when the input clock runs faster than the output 
clock and an underflow condition occurs when the 
input clock runs slower than the output clock. The 
clock tracking option allows the destination 
MDMR output clock to track the source MDMR in- 
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put clock. The output clock tracks the input clock 
for variations of plus or minus .12 percent from the 
nominal input clock rate. 

5.6.3.9 Internal/External Clock . An engineering 
option is available in the selection of a clock choice 
for data transfer of blocked data from an OTU to a 
user. The data transfer is synchronized to either 
an external clock, if a source is available, or an in- 
ternally generated clock, at the specified rate. 

5.6.3.10 Single Data Block Transfer . The single da- 
ta block transfer feature of the MDMR Data Sys- 
tem is an online operating option available to the 
user and does not require scheduling configura- 
tion of the MDMR. The feature is controlled by 
the user's software in real-time operations. It is 
principally intended to accommodate the POCC's 
preferred method of real-time throughput com- 
manding of spacecraft through the MDMR/TDRSS. 
It is only available for user-generated blocked data 
being transmitted to the MDMR Data System at 
NGT. The NGT MDMR is normally operated in the 
unblocked smooth (contiguous) data mode. 

The smooth data mode requires that the demulti- 
plexer wait for the receipt of five data blocks, or 
fora maximum delay of 264 ms from receipt of the 
first data block (whichever occurs first) before be- 
ginning transmission. When the entire data trans- 
mission is a single data block, the single data block 
transfer option allows the user to bypass the 
smooth data mode delay (i.e., allows immediate 
uplinking). To single data block transfer, the user 
must generate blocked data and set the datagram 
bit to a logic 1. The logic 1 datagram bit flags the 
data block as a single block transmission and the 
demultiplexer begins transmission of unblocked 
data immediately upon receipt of the data block. 

5.6.4 SYSTEM OPERATION 

The 4800-bit block is the standard transmission 
format used in the MDMR system. Three block for- 
mats are described in Appendix D of this docu- 
ment. These are: 

a. The GN block, also called the throughput 
block, is used to transmit digital data to and from 
GN sites for support of spacecraft that are TDRSS 
compatible; the GN block is also used for launch 
support of TDRSS compatible spacecraft. 

b. The SN block is used to route digital data 
via the MDMR data system to and from the SN. 

c. The DSN GSFC Interface Block, also called 
the DGIB, is used for transport of command and te- 
lemetry data to and from DSN stations in support 
of TDRSS compatible spacecraft that use the DSN 


for contingency or emergency support should 
TDRSS be unavailable (inoperable) for an ex- 
tended period of time. 

All data transferred between terminals of the 
MDMR Data System are in a 4880-bit block format 
This includes an 80-bit link control header added 
as a prefix by the MDMR systems. The 4800-bit 
block format portion is used for transport of user 
data. The 80-bit link control header is used exclu- 
sively by the MDMR data system for routing and 
message accounting purposes and is transparent 
to the user (the MDMR inserts and removes this 
link control header). 

5.6.5 MACSU 

The original Multiplexer/Demultiplexer Automatic 
Control System (MACS) provided the capability of 
computer-aided monitoring and configuration 
control of MDM system. MACS allowed control 
from local operator positions, or remote control by 
the CSS. The MACS Upgrade (MACSU) was devel- 
oped to replace antiquated hardware and remove 
the memory constraints inherent in the present 
PDP 11/34 computers. The MACSU uses VAX 4000 
series computers. The MACSU has enhanced moni- 
toring capabilities that enable notification to the 
operator in the event of MACSU performance 
problems. The MACSU also provides the capability 
to archive operational changes to disk, and of gen- 
erating alarm and configuration change history re- 
ports. MACSU was installed and operational in 
time to support MDMR project equipment as it 
was integrated into the network in late 1993. 

5.7 STATISTICAL MULTIPLEXER DATA SYSTEM 

This paragraph addresses the Statistical Multi- 
plexer Data System (SMDS) in a standalone 
description. Its role as a major element of the 
HDRS is described in Section 12. 

5.7.1 SYSTEM DEFINITION 

The SMDS can be defined as a Nascom system that 
has the following capabilities: 

a. Interfacing of return link services from 
NGT to JSC, JPL, MSFC, and GSFC for digital data. 

b. A time division MDM system that creates 
four discrete digital channels to timeshare 50 Mb/s 
digital common carrier bandwidth. 

c. Interfacing capability of up to four indivi- 
dual user data streams. 

d. Individual user data rates range between 
125 kb/s to 48 Mb/s. 
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5.7.2 SYSTEM DESCRIPTION 

5.7.2.1 Brief Profile of SMDS . The HDRS consists 
of a Statistical Multiplexer (SM) system and a high 
data rate digital service (up to 50 Mb/s) in a full- 
period, protected, leased Domsat transponder 
broadcast configuration. The system provides a re- 
turn link broadcast transmission capability from 
NGT to user's ground data capture and processing 
facilities at JSC, JPL, MSFC, and GSFC. The SM is de- 
signed to effectively utilize the leased digital 
transmission resource on the domestic communi- 
cation satellite. The SMDS creates discrete chan- 
nels that time-share the total bandwidth in the 
digital mode, with alternate analog and video ser- 
vices provided by the common carrier. The system 
is used to extend high data rate science and image 
data, Orbiter/ Spacelab high rate science, analog, 
and video data to GSFC, JSC, JPL, and MSFC. The 
SMDS was procured by Nascom from Aydin Moni- 
tor Systems. 

5.7.2.2 SMDS System Configuration . The func- 
tional block diagram of the SM is shown in 
Figure 5-9. The SMDS configuration is based on 
the Aydin Model 781 Statistical Multiplexer. 

5.7.23 System Elements . The Statistical Multi- 
plexer principally consists of: transmit section 

(multiplexer). Receive Section (demultiplexer). 


control section, and clock generation section. 
These system elements are described in the follow- 
ing paragraphs: 

a. Transmit Section . The transmit section 
accepts data from up to four input ports at fre- 
quencies from 125 kb/s to 48 Mb/s. The unit mea- 
sures the input clock rate independently on each 
port, buffers the data at each port into separate 
storage queues, and formats the data for output 
based on rate-determined priority. The resultant 
multiplexed 50 Mb/s data stream is output to a 
modem. Pseudonoise (PN) is transmitted by a 
2047-bit PN generator when no port is ready with 
buffered data. 

b. Receive Section . The receive section ac- 
cepts a 50-Mb/s data stream from the modem, ob- 
tains frame sync using the distributed sync pat- 
terns in the data, decodes the port address, and 
routes the data and frequency information to the 
addressed output section. The output sections 
buffer the data in independent storage queues 
and then output the data and clock from the ports 
at the nominal rate of the original data. 

c Control Section . The transmit and receive 
sections share a control section that is based on a 
type 6502 microprocessor. The control section per- 
forms the following functions: 

(1) Provides control and display interface 
with the operator. 



(as of October 1990) 

Figure 5-9. Simplified Functional Block Diagram of the Aydin 
Model 781 Statistical Multiplexer 
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(2) Calculates and displays input frequen- 
cies to six significant digits. 

(3) Determines port input priority assign- 
ments based on rate measurements. 

(4) Adjust receiver output rates to guard 
against output buffer underflow or overflow. 


a. At NGT, the SMDS interfaces with the 
TDRSS KSA Type II return link channels using two 
SM's. 

b. At GSFC, the SMDS interfaces with the 
following: 

(1) Spacelab at Building 23 using two 

SM's. 


(5) Controls updating of the frequency 
synthesizer prescale divider so that there is no dis- 
continuous change in output frequency when a 
synthesizer breakpoint is crossed. 

d. Clock Generation Section . The clock gen- 
eration section uses an external timing reference 
and two internal voltage-controlled oscillators to 
generate the clock signals used by the control, 
transmit, and receive sections. 


(2) Landsat DAF near Building 25 using 
two SM's. 

(3) Nascom Tech Control at Building 14 us- 
ing one SM for monitoring of SM transmissions in 
Building 23 and DAF near Building 25. 

c. At JSC, the SMDS interfaces with the JSC 
MCC at Building 30 using two SM's. 


d. At MSFC, the SMDS interfaces with the 
5.7. 2.4 System Interfaces . As illustrated in MSFC spacelab POCC at Building 4663 using two 
Figure 5-10, the SMDS interfaces with the systems SM's 
at NGT, GSFC, JSC, and MSFC are as follows: ^ 


GSFC 



Figure 5-10. Location Diagram of the SMDS System Terminals 
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e. At JPL, the SMDS interfaces with the 
SRL/SIR-C Ground Processor System (GPS) at Build- 
ing 300 using one SM. 

5.7.3 SYSTEM OPERATION 

5.7.3.1 SMDS Operation . The SMDS operates in 
the following manner: 

a. For the high rate (50 Mb/s) synchronous 
digital data mode of the Common Carrier Domes- 
tic Satellite Transponder Service (CCDTS), Nascom 
provides a special four-channel SMDS capable of 
multiplexing individual user data streams (up to 
four) with individual user data rates between 125 
kb/s - 48 Mb/s into a composite data rate of up to 
48 Mb/s. The SM reserves 2.0 Mb/s of bandwidth 
for system overhead. The capacity of the system 
for user's data is constrained to 48.0 Mb/s. The sys- 
tem is designed to be adaptive to data rate 
changes and to track data rate variations from 
nominal rates indicated due to oscillator variation 
and system Doppler effects within specific tole- 
rances, with the maximum increase above 48 Mb/s 
not exceeding 48.024 Mb/s. 

b. The SN has provided cabling and a dis- 
tribution switching system (DSS-II) at NGT to inte- 
grate the switching of the 14 KSA Type II return 
link channel interfaces. NCC-directed NGT opera- 
tions configure the DSS-II to provide up to four 
digital signals from the Type IIB interfaces through 
the DSS-II to four input channels of the SM. The 
SM multiplexes the input channels and outputs a 
composite serial data stream for transmission to 
the 50 Mb/s data service. A service switch inter- 
faces the digital modulator (see Figure 12-2), while 
the digital modulator interfaces a mode switch be- 
fore the multiplexed data is uplinked to the do- 
mestic satellite. 

c. Demultiplexers of the SM are installed at 
the Landsat DAF, Spacelab Data Processing Facility 
and Nascom Technical Control Facility at GSFC, the 
Spacelab POCC at MSFC, the West Coast Switching 
Center at JPL, and the MCC at JSC. The 
demultiplexers at these user locations demultiplex 
the composite data stream and deliver the data to 
each of its assigned channels. Each stream, at this 
point, is a synthesized replica of the bit synchro- 
nized clock and data stream originated at the in- 
put of the SM at the White Sands interface. The 
SM uses its own data formatting and multiplexing 
technique (that is germane to Nascom) and is 
transparent to the users of the system. Redun- 
dancy is provided in the system with a patchable 
backup SM at each location (except JPL). The SM 
equipment is provided in full duplex for local loop- 
back test capabilities. 


5.7.3. 2 SM Frame Format . The SM is designed to 
accept and deliver user spacecraft raw bitstream 
data. The frame formatting of the bitstream data, 
as illustrated in Figure 5-11, is described in the fol- 
lowing paragraphs: 

a. At the transmit section, each of the four 
ports receives an ECL balanced channel of data 
and clock. The serial data is converted to 31-bit 
parallel words organized into 248-word frames. 
These frames are then formatted into 250 32-bit 
words that include distributed sync, frequency, 
and port address information. The sync infor- 
mation is attached, one bit per word, to the end of 
each of the first 248 words. The sync pattern in the 
last 31 words of the 248 provides end-of-frame 
information. Words 249 and 250 contain the port 
frequency and the frame sequence number. The 
formatted frames are passed to the communi- 
cations link modem at 50 Mb/s. When no data is 
available from any of the input ports, PN data pat- 
tern 2047 is generated for transmission. 

b. At the receive section, the 50 Mb/s data 
stream from the communications link modem is re- 
ceived in the rear panel. The frames are synchro- 
nized into 32-bit words and a clock pulse is devel- 
oped to occur simultaneously with the distributed 
sync bits in the data stream. The port address and 
end of frame are determined from the distributed 
sync pattern. Each data frame is converted into 
32-bit parallel words corresponding to the trans- 
mit section. The overhead information from the 
data frame is removed, and converts the data back 
into serial form. 

5.8 CONTROL AND STATUS SYSTEM 

This paragraph provides a standalone description 
of the CSS. Its role in supporting the scheduling 
and configuration function of the BDS and HRDS is 
discussed more comprehensively in Sections 1 1 and 
1 2, respectively. 

5.8.1 SYSTEM DEFINITION 

The CSS, as a Nascom System, can be defined as the 
vehicle through which the communication 
resources of the Nascom Network supporting the 
SN will be scheduled and configured. 

5.8.2 SYSTEM DESCRIPTION 

5.8.2. 1 Development History . The CSS was deve- 
loped to provide the SN with a system apparatus 
needed to automate the schedule-driven data 
traffic control capability and network status in- 
formation for the various Nascom Network ele- 
ments supporting SN. The development history of 
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PSO THRU P530 REPRESENT A DISTRIBUTED PATTERN USED TO 
PROVIDE END-OF-FRAME DETERMINATION. 


Figure 5- 1 1. Frame Format of the SM Bit Stream Data 


the CSS is summarized in the following para- 
graphs: 

a. Control and Status System Development. 
The CSS has been a major augmentation for the 
Nascom/SN data transport system and has been 
beneficial in automating the prior manual con- 
figuration of ground communications equipment 
supporting TDRSS users. Having operated in a RED 
mode for several years, system changes enabled 
the CSS to be color changed in 1991 back to its 
original design: operating in a BLACK mode. 

b. The CSS development has been imple- 
mented in two parts as follows: 

(1) Acquisition of hardware through com- 
petitive procurement resulting in acquisition of a 
Sperry 1100/62 Federal Information Processing 
Standard (FIPS) compliant processing system. 

(2) In-house development of software 
through task order via the Nascom Contractor En- 
gineering Support Team. 

* 

c. Except for a recently initiated front end, 
mass storage and tape drive replacement project, 
the CSS acquisition is considered to be complete. 


Further enhancements in the form of a new host 
processor are being contemplated. Subsystem 
software requirements have recently been up- 
dated and are under review. A phased implemen- 
tation plan was adopted, under which a minimum 
required operational capability was delivered at 
the end of the first quarter of 1987 (Phase I), and a 
more complete capability was delivered during the 
first three quarters of 1988 (Phase II). 

d. In the first phase of implementation the 
CSS acquired the capability of accepting Nascom 
Event Scheduling (NES) messages from the NCC 
and from a local operator and controlling the 
MDM and SM. 

e. Implementation of CSS Phase I also 
required delivery of a CSS Emulator, which is a 
primary test tool to be used in testing of CSS prior 
to online operation. The Emulator consists of 
software capable of limited emulation of all 
external interfaces of the CSS; i.e., the various 
subsystem interfaces described in paragraph 
5. 8.2.4 and the NCC interface. 

f. Capabilities for processing status or alarm 
information for its subsystems, generating 
response messages to the NCC, controlling the 
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DMS, and generating and distributing the advance 
schedule via TTY messages were provided in Phase 
II. 

g. Software acceptance testing of all CSS 
Phase II releases was successfully accomplished in 
September 1988. 

h. The CSS was tested successfully with the 
DCS in July 1989. DCS is now online with the CSS. 

i. An independent software development 
computer system with compatible software and in- 
terfaces (Swift 2200/200) permits software devel- 
opment activity to occur with minimum release 
time of CSS on-line assets. 

j. Code 530 developed and installed a CSS 
at NGT to control the MDM and SM equipment. 
The CSS was modified to interface with the NGT 
CSS (NCSS) for status only. 

k. Certain capabilities originally intended in 
Nascom CSS System Requirements Specification 
541-001, were not accomplished in Phase I and II. 
A software enhancement effort was designed to 
complete certain system requirements and certain 
newly identified requirements that were deferred 
in the original implementation. 

(1) Software Enhancements. 

(a) Release 91.3 was developed to con- 
trol the MACS, which control the old MDMs. 

(b) Release 92.2 was developed to con- 
trol the upgraded MACS, which control the new 
MDMs. 

(c) Release 94.1, scheduled for delivery 
in the final quarter of FY 94, includes the ability to 
handle the 3-character TDRSS identifiers, as well as 
supporting the NCC Level 6 testing. Support for 
STGT and WSC are also included in this release. 
Following successful completion of ORR for Re- 
lease 94.1, CSS software development enters the 
support and maintenance mode. 

(2) Hardware upgrade. An upgrade of 
the processor has been procured: UNISYS model 
2200/400 computers. The equipment is scheduled 
for installation and implementation in conjunc- 
tion with Release 94.1 of the CSS software. 

5.8.2.2 CSS Configuration . The CSS is a computer 
system that automates the scheduling and config- 
uring of Nascom resources committed to support 
oftheSN. 


5.8. 2.3 System Elements . The hardware system 
elements are the central complex cabinets housing 
the UNISYS 2200/400 processing systems, system 
support processors, system consoles, FEPs and as- 
sorted peripheral devices. The software system 
consists of the vendor and application software. 
The software system elements are briefly de- 
scribed in the following paragraphs: 

a. Vendor Software . The vendor software 
shown in Figure 5-12, consisting of Unisys- 
supported products such as OS, utility programs, 
diagnostics, and other system programs required 
to operate the UNISYS 2200/400 computers and 
peripheral devices configured for the CSS. Vendor 
software includes system- or machine-specific pro- 
grams that support a set of general functions for 
the CSS. The vendor software follows: 

(1) Transaction Interface Processor (TIP) 
System . An extension of the Series 1 100 EXEC OS 
that allows immediate execution of transaction 
programs. 

(2) Message Control Bank . A general- 
purpose message-handling mechanism that pro- 
vides the capabilities of controlling and recovering 
input and output messages. 

(3) Data Management System 1100 
(DMS1100) . A system that allows users to define 
the data base and the various user views of the da- 
ta base. 

(4) Integrated Recovery Utility (IRU) . A 
program that provides a set of language com- 
mands for the recovery and reconstruction of 
TIP/DMS files. 

(5) Command Management System 1100 
(CMS1100) . A system that provides a real-time in- 
terface for routing communications data from 
hardware devices to the 1100 EXEC OS. 

(6) DCP OS . DCP OS handles information 
queries from its own application and provides 
boot capabilities and file services. 

(7) TELCON . TELCON provides (1) data 
send and receive capability to the operator termi- 
nals, (2) Advance Schedule via the CMS1100, and 

(3) Nascom line modules to and from the host. 

b. Application Software . Application soft- 
ware consisting of function-specific programs that 
enable the execution of application processes 
specified for the CSS. This software is developed 
in-house by a contractor according to Nascom 
specifications. Application software cannot be ex- 
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Figure 5-12. Vendor Software Configuration 


ecuted in the computer by itself; it requires the 
operating system program provided by the ven- 
dor. 

5.8.2.4 System Interfaces . The CSS system inter- 
face configuration is illustrated in Figure 5-13. All 
interfaces shown are Nascom internal control and 
status interfaces, except for the interfaces with the 
NCC. The CSS Systems interfaces are described as 
follows: 

a. NCC Interface . The CSS interfaces the 
NCCDS with two 56 kb/s data lines routed via the 
Nascom MSS and the NCC Restricted Access 
Processor (RAP). (These 56 kb/s data lines are still 
routed via the PDS installed in the 1980s for 
support of classified DoD shuttle operations, an 
activity now discontinued.) Message interchange 


be-tween the NCC and the CSS are in standard 
4800-bit blocks. The NCC is constrained by 
Interface Control Document (ICD) agreement to a 
maximum transmission rate of eight blocks per 
second. NES messages may be multiblock 
messages. The definition of messages by type, 
class, content, and protocol for interchange 
between the NCC and CSS is contained in STDN 
220.9 “Interface Control Document between the 
Network Control Center and the Nascom Control 
and Status System." 

b. Subsystem Interfaces . On the basis of the 
NES messages received from the NCC, the CSS 
performs a resource allocation, produces a Traffic 
and Configuration Time Schedule (TCTS), and 
issues TCTS time-driven command blocks to the 
subsystem control elements. The CSS also 
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NOTES: 
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Figure 5- 13. CSS Functional Interface Block Diagram 


GROUND COMMUNICATION 5-22 











540-030 

FY94-2 


maintains a data base of available Nascom system 
resources and updates it based on status data 
received from subsystems. 

c. NCSS Interface . Since the NGT CSS con- 
trols the NGT equipment, status information is 
sent to the CSS from the NCSS via the Block For- 
matter. 

d. Block Formatter Interface . The Block For- 
matter (BF) is a Nascom subsystem element that 
was developed for each of the four installations 
(NGT, JSC, and two GSFC SM locations). It multi- 
plexes block status information from the MDM, 
SM, and DIMS at NGT and JSC for transmission to 
the CSS, and distributes schedule-driven control 
messages from the CSS to the MDM. The SM's (and 
the Mode Switch at NGT) require external block 
formatting/deblocking capability, which is also 
furnished by the BF. The BF is capable of block 
multiplexing/demultiplexing 6 channels, and will 
handle 1200 bit blocks. The BF is required in con- 
junction with the CSS for implementation of auto- 
mated scheduling and control of the Nascom SN 
elements. In-house fabrication, assembly, and 
testing were completed as of March 1985. Installa- 
tions were completed in conjunction with CSS 
Phase I at the end of the second quarter 1987. 

(1) A total of eight BF's plus supporting 
equipment are installed, two each, at the follow- 
ing locations: 

(a) Landsat Data Acquisition Facility 
(DAF) near Building 25 at GSFC. 

(b) Spacelab Data Processing Facility in 
Building 23 at GSFC. 

(c) Communications Circuit Technical 
Control Facility in Building 30 (Mission Operations 
Wing) at JSC. 

(d) NGT at White Sands, New Mexico. 

(2) The BF's are arranged in a hot-standby, 
redundant configuration. Each BF is capable of 
interfacing two SM's, one MDM MACS, and three 
DLMS units to the CSS. The BF select switch, which 
is part of the installation, provides switching func- 
tions of their BF serial, RS-422 interfaces. These 
functions include a 2 x 2 switch to route two com- 
munication links to/from the two BF's, as well as a 
2x1 switch to route the MACS and DLMS to/from 
either of the two BF's. The SM switch switches the 
interface of two SM's to/from the two BF's. 

The CSS communicates with Nascom subsystem 
control elements in 1200-bit blocks and 56-kb/s in- 
terfaces. The MDM, DLMS, SM, and DMS control 


subsystems are compatible with the 1200-bit block 
56-kb/s interfaces. The 4800-bit block is used on 
the NOC interface. For CSS communications with 
the NGT and JSC locations, the BF also performs a 
block multiplexing function for efficient utili- 
zation of 56-kb/s circuits to be established be- 
tween GSFC and remote locations for the CSS func- 
tion. These 56-kb/s control circuits established ex- 
ternal to the MDM systems for a normal oper- 
ational diversity configuration, but may use chan- 
nels within the MDM system (serial data mode) as 
an alternate path. 

e. Statistical Multiplexer Interface . The SM 
A and B shown at GSFC represent the system con- 
trollers of separate SM equipment locations for 
the SLDPF and the Landsat DAF interfacing individ- 
ually to the CSS via BF's. 

f. DLMS Interface . Each of the three BDS 
locations (NGT, JSC, and GSFC) will have two 
DLMS, one for each alternate downlink (A and B 
system), which will periodically send link status to 
the CSS. The DLMS provides status only, and re- 
quires no CSS commanding function. At GSFC, the 
DLMS interfaces directly with the CSS to provide 
link status. At NGT and JSC, the DLMS interfaces 
via the BF and at NGT indirectly via the NCSS. 

g. MDM Interface . The MDM system is 
interfaced directly to the CSS at GSFC, and via the 
BF at NGT and JSC for control and status functions. 

h. TTY Interface . The CSS also interfaces 
with a 1200-baud TTY circuit for transmission of 
the 24-hour advance schedule, which is sent to a 
Receive-only Printer (ROP) at the local MDM oper- 
ating positions at JSC and GSFC Nascom Tech Con- 
trol for manual execution of the schedule (if need- 
ed) as a backup to the CSS. A translation of the 
4800-bit block NES messages into identifiable 
instructions in TTY message form is accomplished 
in the CSS. The advance schedule for NGT is also 
transmitted by the NCC directly to the NGT Sched- 
uling System (NSS) via a separate 56-kb/s channel. 

i. DMS Control System Interface . The DMS, 
located at GSFC, is a three-stage, solid-state, circuit 
switch composed of a forward matrix and backup , 
return matrix and backup, and a control sub- 
system. Each of these four matrices is capable of 
handling 192 input and output lines. The function 
of the DMS in the SN is to route TDRSS/NGT/JSC 
MDM traffic flows to/from users and operators 
of the SN via GSFC. The CSS at GSFC will be used 
to automatically configure and monitor the status 
of the DMS, in accordance with the NCC schedule. 
The current DCS is a DEC MicroVAX II. 


GROUND COMMUNICATION 5-23 



540-030 

FY94-2 


5.8.3 SYSTEM OPERATION 

5.8.3. 1 CSS Subsystem Operations . The CSS oper- 
ation is premised on the functions specified for the 
system. The functions of CSS, as depicted in 
Figure 5-14, are grouped into three main sub- 
systems. These are: 

a. El Subsystem. Manages the communica- 
tions interfaces between the CSS and other net- 
work elements. As can be seen in Figure 5-13, the 
NCC is included as an element, in addition to the 
various network equipment at each of the sites. 

b. TCTS Subsystem . Receives daily Nascom 
event schedules from the NCC via El or from the lo- 
cal operator via 01, configures the network equip- 
ment in accordance with the schedule, and moni- 
tors the network status. 

c. 01 Subsystem . Provides for operator con- 
trol of CSS and network activities. 

5.8.3.2 Fundamental CSS Processes in Sub- 
systems. There are seven identified fundamental 
processes operating in the subsystems to perform 


the functions. The acronym placed after a process 
indicates the subsystem where the process occurs: 

a. Manage NCC/CSS interface communi- 
cations (El). 

b. Manage Network/CSS interface commun- 
ications (El). 

c. Manage JSC SN/CSS interface communi- 
cations (El). 

d. Schedule Nascom events (TCTS). 

e. Command network configuration (TCTS). 

f. Monitor network status (TCTS). 

g. Interact with operator (01). 

5.9 NASCOM ENVIRONMENTAL SUPPORT SYS- 
TEM 


5.9.1 SYSTEM DEFINITION 

The Nascom Environmental Support System refers 
to the various systems that support the environ- 


EQUIPMENT INTERFACE (El) TRAFFIC CONTROL TIME SCHEDULE (TCTS) 


OPERATOR INTERFACE ( 01 ) 
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mental requirements of the primary switching and 
technical control facilities at GSFC in the areas of 
electric power, emergency lighting, and air condi- 
tioning. 

5.9.2 SYSTEM DESCRIPTION 

5.9.2.1 Primary Power . Primary power to Build- 
ings 3 and 14 is provided by two separate commer- 
cial feeders backed up by four 500-kVA diesel gen- 
erators. During critical mission periods, the diesel 
generators are kept running continuously. 
Nascom does not utilize the diesel power source 
unless commercial power becomes unstable or 
fails. Special power switching arrangements are 
provided such that the Voice Switching System 
(VSS), Control and Status System, and Technical 
Control areas and their associated UPS's can be 
automatically supplied from either the commercial 
or diesel power sources. In the event of failure of 
either power source, these loads are automatically 
(or manually) switched to the remaining unfailed 
source. 

5.9.2.2 Uninterruptible Power System . Three 
separate UPS's provide for a continuous power 
feed to Nascom's Voice Switching System, the Con- 
trol and Status System, the Digital Matrix Switch, 
and the Technical Control area. The UPS's operate 
on a battery/converter principle with the battery 
system permanently floating on-line. When com- 
mercial power fails, no switching is required: the 
batteries assume the critical load instantaneously 
until commercial power is restored or the diesels 
are brought on-line. In this manner, critical sys- 
tems and circuits which must be protected from 
power fluctuations are assured stable, reliable 
power. 

5.9.2.2.1 Voice Switching System UPS. The Voice 
Switching System UPS consists of two identical bat- 
tery chargers and four battery banks providing for 
a minimum of four hours operation without an ex- 
ternal alternating current (AC) power source. 

5.9. 2.2.2 Technical Control System UPS. The Tech- 
nical Control Area systems are supported by three 
identical UPS's. These UPS's provide an operating 
period on battery of about 15 minutes. Currently, 
these UPS's are loaded at about 70 percent of their 
rated capacity. 

5.9.2.3 Emergency Lighting . Emergency lighting 
is provided by one 30-kVA no-break power systems 
which provide power to selected fluorescent fix- 
tures in Building 14. 


5.9.2.4 Air Conditioning . Air conditioning is 
provided by the GSFC chilled water supply. Two 
standby water chillers with 250-ton and 125-ton 
capacities (located in Building 3) can be arranged 
to supply air conditioning in the event of failure of 
the GSFC chilled water supply. Three separate air- 
handling units, located in Building 14, provide 
cooling for the equipment and afford 
approximately 50 percent redundant capacity. 
With this margin, any two of the three units are 
capable of handling the anticipated total heat 
load generated when all equipment is operated 
simultaneously. 

5.10 NASCOM TECHNICAL CONTROL SYSTEM 

5.10.1 SYSTEM DEFINITION 

The Nascom Technical Control System refers to 
arrays of test, patch, monitoring and diagnostic 
capabilities arranged on a functional subsystem 
basis for support of Nascom TTY, Data, and Video 
services. 

5.10.2 SYSTEM DESCRIPTION 

5.10.2.1 TTY Tech Control . The TTY Tech Control, 
located in the Building 14 TTY operational area, 
consists of rack-housed jackfields and test equip- 
ment used for configuring, testing, and monitor- 
ing of the TTY circuits, including the restoration 
and/or replacement of TTY equipment. 

5.10.2.2 Data Tech Control . The Data Tech Con- 
trol, located in the Building 14 communications ar- 
ea, consists of an extensive array of bay racks hous- 
ing the test and patch subsystems used for test ac- 
cess, reconfiguration and/or restoration, testing, 
and monitoring of data channels. From the High- 
speed Data Technical Control area, the capability 
to test and monitor analog [alternate voice/data 
(AVD) and TTY] as well as digital data channels, 
and order wires, is provided. Another area is 
called the Wideband Data Tech Control, which is 
used for the test and monitoring of wideband da- 
ta circuits. 

5.10.2.3 Video and Timing Tech Control . The Vid- 
eo and Timing Tech Control, (Tech Support) lo- 
cated in Building 14, consists of an extensive array 
of bay racks housing the video test and monitoring 
equipment, and test and patch facilities (including 
the video consoles for video signal control). Video 
Tech Control operates jointly with TV Central Con- 
trol, located at Room N-2, Building 8, which is also 
operated by Nascom but under Code 543. 
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5.11 NASCOM DATACOM-TECHNICAL SUPPORT 
FACILITY AND INTER-BUILDING CABLE NET- 
WORK 

5.11.1 DATACOM-TECHNICAL SUPPORT 
FACILITY 

Operated by Code 543, the DATACOM-Technical 
Support Facility is located in Room E-2, Build- 
ing 14. It consists of the following equipment: 

a. Remote-control POCC video switching and 
distribution matrix 

b. Termination frame for the GSFC Inter- 
Building Cable Network 

c. Time standards generator and distribution 
system 

d. Interface for internal extension of com- 
mercial carrier supplied video and audio circuits 

e. Audio terminal for Mission Operations 
audio and General audio 

f. Main-frame for control of all remote- 
controlled cameras 

5.1 1.2 GSFC INTER-BUILDING CABLE NETWORK 

5.11.2.1 General . Managed and operated by Code 
543, the GSFC Inter-Building Cable Network is 
comprised of twisted pair, coaxial and fiber optic 
cables. Over this cable network are transported 
television, audio, computer-to-computer data, 
data to and from interfaces external to GSFC, and 
spacecraft data for operational and testing 
support between Goddard control centers and 
their respective spacecraft. Each building 
connected to the cable network has cable- 
appropriate termination frames or racks on which 
the outside cables serving the building are 
terminated, including appropriate audio and 
video outlet boxes. Within each building are 
“house cables" that interface to the outside plant 
cables at these frames/ racks used to extend circuit 
paths to the end user's facilities. 

5.11.2.2 Obtaining Service. To obtain a cable cir- 
cuit on GSFC, the requiring office submits its re- 
quirements in writing to Nascom's Telecommuni- 
cations Branch, Code 543. Each request needs to 
contain the following information: 

a. Types and quantities of circuits 


c. Period(s) of support 

d. Building and room number where service 
is required 

e. Name and phone number of person who 
will be point of contact to work with Code 543 to 
implement the requested service 

Upon receipt of a service request, Code 543 deter- 
mines the availability of appropriate cable(s) to 
the service location and identifies the routing and 
circuit configuration for the requested service. 
When the circuit is established, it is tested end-to- 
end (on-site) to demonstrate compliance with ser- 
vice requirements. If the on-site segment of a cir- 
cuit is being implemented to meet a Nascom re- 
quirement, then Nascom may supply conditioning 
or line-driver equipment if necessary for the circuit 
to function properly. 

If there is a circuit problem after activation of the 
on-site circuit, the user opens a trouble report with 
Nascom. The circuit is then turned over to Nascom 
for fault isolation and correction by CCTV- 
DATACOM personnel of Code 543. If the problem 
cannot be corrected, then the service will be re- 
stored on a similar cable, if one is available. 

5.11.3 MISSION-ORIENTED FIBER OPTIC CABLE 
PLANT 

5.11.3.1 General . To support the ever increasing 
requirement for extending digital circuits between 
buildings housing operational mission supporting 
facilities, the Nascom Telecommunications Branch 
maintains an extensive and growing fiber optic ca- 
ble plant. This fiber optic cable plant centers on 
Building 14 (Nascom GSFC Switching Center's loca- 
tion) and provides connection to and between 
buildings housing operational, mission-oriented 
facilities. 

5.11.3.2 Description . Nascom's fiber optic cable 
plant consists of fiber optic cables possessing the 
following characteristics: 

Type: multimode 

Size: 50/125/250 microns 

Numerical Aperture: 0.20 

Attenuation: 400/1000 Mhz @ 2. 5/1. 5 dB/km 

Type: multimode 

Size: 62.5/125/250 microns 

Nmberical Aperture: 0.275 

Attenuation: 1.5dB/km/500 Mhz@1300nm 


b. Data rates to be transported 
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0 Building Number 
Fiber Optic Cable Path 

n — Number of optical Fiber cables 50/125/250 micron 400/1 000 MHs/KM 
(n) Number of Optical Fiber cables 62.5/1 25/250 micron 
n-SM Number of Optica! Fiber cables Single-mode 

□ Future- Planned Building and Connectivity loral 54<voio-225m 


Figure 5- IS. Operational, Mission-Oriented Nascom Interbuilding Fiber Optic 

Ca ble Plant on GSFC 
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Type: single-mode 

Size: 8-9 micron 

Attenuation: 0.4/1 3 10-1 550nm 

From the principle node in Building 14, cables fan 
out across GSFC. Route diversity to selected 
buildings is achieved through intermediate patch 
facilities (nodes) in buildings 10, 11, 23, 28 and 29. 
Figure 5-15 portrays the operational, mission 
supporting fiber optic cable plant currently 
installed on GSFC. Cables for support of the ICLU 
project (paragraph 17.4.7) are shown on this 
drawing. 

5.12 SECURITY OF NASCOM SYSTEMS 

5.12.1 ADP SYSTEM RISK ANALYSIS 

5.12.1.1 Background Information . The Nascom 
organization has been required to assess 
vulnerabilities and the feasibility of additional 
safeguards for its Automatic Data Processing 
(ADP) systems, where appropriate. These analyses 
are used by NASA/GSFC Computer Security Offi- 
cials (CSO), in compliance with various directives 
on this general subject. Those directives include 
the Office of Management and Budget (OMB) Cir- 
cular No. 130, the NASA Management Instruction 
(NMI) 2410.7, and the NASA Handbook (NHB) 
2410.9. 

5.12.1.2 Nascom Activities . The ADP Equipment 
(ADPE) risk analysis is a continuing activity that re- 
quires periodic reassessments. Accordingly, 
Nascom has tasked its Nascom Maintenance and 
Operations Support (NMOS) contractor to provide 
support to the Nascom Division CSO. Risk analyses 
have been performed for each of the following 
systems and reassessments are conducted on a 
continuing basis: Interconnect Telecommunica- 
tions Systems (ITS), Goddard electronic mail system 
(GSFCMail), Nascom System Engineering Manage- 
ment System (SEMIS), and Nascom Operations Sys- 
tem (a collective designator for the MSS, MACS, 
CSS. DCS, DDCS, VSS, and VDS). 

5.12.2 NASCOM ACCESS CONTROL 

5.12.2.1 Background Information . NASA Code O 
(OSC) has established a NASA-wide policy regard- 
ing Nascom access control [refer to Memorandum 
TS-88-246 (August 1, 1988)] and NMI 2520. ID. The 
policy requires that users of Nascom services survey 
their resources and determine the applicability of 
their Nascom interconnecting systems and compli- 
ance with policy. Purpose of the policy is to pre- 
vent unauthorized access and potential damage to 
Nascom operational systems and user Automated 
Information Systems (AIS). 


5.12.2.2 Nascom Responsibility . Nascom has been 
given responsibility to verify compliance through 
unannounced audits at Network user sites. The 
SEAS contractor has been tasked to support the 
Nascom CSO by forming a security audit team to 
carry out this policy. The schedule and identity of 
installations are determined by Nascom. The con- 
tractor furnishes a detailed written report follow- 
ing each site visit. This is, and will be, an ongoing 
and continuing activity. Specific details are found 
in NASA Communications (Nascom) Access Protec- 
tion Policy and Guidelines (541-107). 

5.12.3 NASCOM PHYSICAL SECURITY ARRANGE- 
MENT 

The physical security system established for the 
Nascom Network consists of the following: coded 
lock access for operational areas, access proce- 
dures, and badge systems, earth station fencing, 
limited access area delineation, closed circuit TV 
surveillance, and contractor clearances. 

5.12.4 SECURE NASCOM SYSTEMS 

5.12.4.1 Multiplexed Circuits . The following 
wideband circuits/systems are encrypted at the ag- 
gregate interface of the multiplexer: 

a. NCC/NGT (sole remaining link of the ISC). 

b. CSTC/NCC. 

5.12.4.2 Non-multiplexed Circuits . The 56 kb/s 
circuit for the NGT communications hardware con- 
figuration and status remains encrypted pending 
completion of the NGT guard processor project. 

5.12.4.3 RED Information Transport Practice . For 
intercenter wideband trunks terminating in 
Nascom managed time division link multiplexer 
equipment, it is now the practice to implement the 
occasional requirement for classified voice and da- 
ta signal transport with user supplied and installed 
RED sub-multiplexers, located in secure user facili- 
ties, the encrypted aggregates of which are inter- 
faced as BLACK synchronous data signals to appro- 
priately configured data channel cards of the link 
TDM's. 

5.12.4.4 Historical Note . The multi-node secure 
network known as the Integrated Secure Commu- 
nications System (ISC) has been deactivated as a re- 
sult of changes in the Air Force program which 
originally generated the requirement for the ISC. 
ISC nodes at MSFC, JSC, GSFC (with extension to 
NASA Headquarters), MIL and CCAFS have now 
been deactivated; as indicated in paragraph 
5.12.4.1, only the GSFC NCC/NGT link of the ISC re- 
mains active. 
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for interface with the voice system. All of these 
systems provide analog/digital conversion for 
integrated services transport, and some of them 
also provide data encryption for protection and/or 
security. These systems are briefly summarized in 
the following paragraphs. 

7.5.1 TDMA 

The Nascom/TDMA system provides the capability 
to establish point-to-point circuits between any 
combination of 14 TDMA installations at NASA 
and DOD locations. Each TDMA terminal is pro- 
vided with at least one D-3 channel bank capable 
of terminating 24 local voice circuits. The D-3 
channel bank equipment provides analog-to- 
digital conversion for integrated system digital 
transport compatible with T-1 multiplexing. The 
TDMA multiplexer equipment provides split chan- 
nel operation, allowing the circuits to be individ- 
ually assigned to communicate with any terminal 
in the TDMA Network. Authorized voice circuit 
connectivities established in the TDMA system are 
not considered to be dedicated full-period circuits, 
but are set up as required in accordance with daily 
schedules by the GSFC/NNSG. At GSFC, a 24-voice 
circuit interface is established between the local 
TDMA terminal and the voice control facility. 
Twenty-three voice circuits from GSFC to other lo- 
cations are authorized in the TDMA system. These 
circuits are interfaced to the VSS and activated 
from an RTC when scheduled. Refer to Section 3 
for a description of the Nascom TDMA Network. 

Nascom plans to deactivate the TDMA network on 
or about October 1, 1994. Services formerly pro- 
vided via the Nascom TDMA will be transitioned to 
the FTS2000, NSAP I. Currently these services will 
be limited to T-1 (1.544 MBS) rates. Requirements 
in excess of a T-1 rate must be reviewed, validated, 
and provided independently. 

7.5.2 SECURE/PROTECTED VOICE SYSTEMS 

7.5.2.1 General . Secure and/or protected voice 
systems use digitized voice and are encrypted for 
protected transmission. 

These transmissions terminate in secure areas. 
Wideband digital data services provided by 
Nascom are utilized. Circuits are derived by digital 
TDM multiplexers which integrate voice and data 
channels for transport. Secure/protected voice 
channels are not terminated in the VSS. 

7. 5.2.2 ISC. The one remaining ISC trunk provides 
a capability for the secure transport of RED voice, 
data and facsimile signals between the NCC and 


the NGT/WSGT (to be followed by STGT when that 
facility is operational). 

7.6 VOICE DISTRIBUTION SYSTEM (VPS) 

7.6.1 BACKGROUND INFORMATION 

To provide GSFC POCCs and other local users with 
a campus wide operational voice distribution ca- 
pability that is reliable, flexible, and permits a high 
degree of user interaction with the system for con- 
trol of each user's voice circuit/loop allocations, 
Nascom contracted with COMPUNETICS, Inc. to 
furnish and install a voice switching system to 
meet the GSFC requirements for on-campus oper- 
ational voice switching and distribution. Two sig- 
nificant requirements met by the VDS are the in- 
corporation of digital switching technology and 
compliance with applicable ISDN standards for 
2B + D service. 

The VDS system was installed in 1992 to provide 
operational voice communications between 
POCCs for scheduling, command and control, and 
element coordination. Users were cutover from 
the old voice intercom system to the VDS for 
operational support during the first half of FV 93. 
Acceptance testing was completed in October 
1993. 

7.6.2 SYSTEM HARDWARE AND 
CONFIGURATION 

The VDS switch is installed in Building 14 and 
comprises 12 equipment bays allocated as follows: 

a. 1 Switch Control Bay 

b. 4 ISDN Bays 

c. 1 Analog Line Interface Bay (2 & 4 Wire) 

d. 1 Input Switch Bay 

e. 2 Conference Bays 

f. 1 Output Switch Bay 

g. 2 TDM/OSS Bays 

Also located in Building 14 is the Maintenance and 
Administration Position (MAP) for the VDS. The 
MAP resides on redundant PCs. The VDS UPS is 
colocated in Building 3 with the VSS UPS. 

Power for the VDS bays is supplied as 208 VAC 
single phase from two 208 VAC inverters. The two 
MAPs are supplied 1 20 VAC single phase from one 
120 VAC inverter. All three inverters are fed by 
four banks of 48 VDC lead-calcium batteries. 
These battery banks are supplied by six identical 
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rectifier units which in turn are fed by 208 VAC 
three phase commercial power. The batteries also 
provide 48 VDC power to breaker panels located in 
the telephone closets where it is distributed to the 
individual instruments. The batteries are capable 
of providing 4 hours of backup power at full load 
without recharge. A power monitoring system 
displays voltage and current levels and alarm 
conditions. 

Switch architecture supports path verification and 
an availability number that should approach 
100%. Each circuit through the switch between 
any two ports is a physical path; TDM techniques 
whereby multiple ports time share a path are not 
employed. The system controller is triple 
redundant and performs Input/Output port path 
verification prior to establishing a connection; idle 
paths are periodically checked, and if a fault is 
found, that path is disabled and alarmed/reported 
at the MAP. Figure 7-3 depicts a functional 
representation of the VDS. 


Allocated to users across the Goddard campus are 
600 ISDN Instruments and 6 POCC Utilization 
Management Positions (PUMPs) the latter of 
which enable the POCC managers to prepare, 
store, and control the configuration of their 
allocated circuits and loops to their instruments. 
Table 7-1 summarizes the VDS system capability. 

7.6.3 VDS INSTRUMENT FEATURES 

There are four different types of instruments that 
the VDS offers to its users: keyset (KS), mechanical 
keyset (MKI) and single line instrument (SLI) and 
Digital Keyset (DKS). The following paragraphs 
describe each instrument type. 

7.6.3.1 Keysets (KS) . The KS provides a 28 key 
electroluminescent touchscreen, 12 elastomeric 
standard dial telephone keys, a 1.5 watt speaker 
and handset with a push-to-talk feature mounted 
on a 7 x 19 inch EIA standard panel. Electronically, 
the KS stores 10 touchscreen pages, each page 
with 28 keys, for a total capacity of 280 circuits. 



Figure 7-3. Voice Distribution System Operational Block Diagram 


(as of August 1993) 
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Table 7-1 


Summary of VDS Capai 

bilities 

Communication Service Type 

Installed 

VDS Internal 
Wired 

Additional 

Expandable 

Overhead Speakers 

456 

- 

500 

VSS Interfaces- 4 wire 

400 

- 

752 

CBX 

128 

80 

176 

IDSN (User Instruments) 

600 

24 

656 


ISDN units are composed of keysets, n 
keysets, and single line instruments, 
types is not fixed, but rather, depend 

nechanical 
fhe mix of these 
son user needs. 

VDL Hotlines 

100 

- 

20 

Conference Ports 

- 

- 

- 


Has no external significance in that conferencing has a 
different meaning inside VDS. 


The KS supports local SCAMA lines, CCLs, CBX, VDL 
and Dl circuits. With the exception of the Dl circuit 
which is talk/listen only, the KS may terminate 
these circuits in one of three selectable modes: 
talk/listen, loudspeaker monitor, handset monitor. 
Additionally, the KS is equipped with a HOLD and 
Active Circuit Indication features. 

7.6.3.2 Mechanical Keyset (MKI) . The MKI 
provides a desk-mounted (with reversible base for 
wall mounting) instrument equipped with 
hookswitch, elastomeric keypad, and push-to-talk 
handset. Electronically, the MKI has a page 
selector capability of two pages at ten circuits per 
page for a total capacity of 20 circuits. The MKI 
terminates the same kinds of circuits as the KS and 
in the same modes. Additionally, the MKI is 
equipped with HOLD and SIGNAL button features. 

7.6.3.3 Single Line Instrument (SLI) . The SLI 
provides a desk-mounted (with reversible base for 
wall mounting) instrument equipped with 
hookswitch, elastomeric keypad, and push-to-talk 
handset. Electronically, the SLI can terminate only 
one circuit at a time, and that circuit may be 
terminated in the same modes as the MKI or KS. 
The SLI also has Signal Button, Hold Button, and 
Busy Lamp features. 

7.6.3.4 Digital Keyset (DKS) . The DKS has been 
identified for use in accommodating the growing 
number of users. The primary use of the DKS will 
be to replace the MKI at NASA Headquarters. 
Specifics on the DKS were not available at the time 
of publication. 


7.6.4 MAP FUNCTIONS 

There are two MAP positions provided with the 
VDS. Both MAPs are online and function 
redundantly. The MAP positions are comprised of 
standard IBM PC-AT equivalent personal 
computers equipped with a color monitor and a 3 
1/2“ high density floppy disk drive. The MAP 
performs the following functions: 

a. VDS system data base maintenance 

b. POCC Utilization Management Position 
(PUMP) emulation 

c. Report generation 

d. User account maintenance 

e. The MAP also comes with file transfer 
utilities 

7.6.5 PUMP FUNCTIONS 

Sixteen PUMPs are provided with the system 
capable of incrementing that number up to a total 
of 25. The PUMP platform is the same as that of 
the MAP. Each PUMP has the capability to 
perform the following POCC/user functions: 

a. Configure the resources (circuits, loops, 
dial accesses), as allocated to the POCC by 
the master data base resident in the MAP, 
among the various instruments installed in 
the POCC or user facility. 

b. Save/restore individual instrument 
configurations 
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c. Save/restore the master POCC 
configuration(s) 

d. Download background configuration sets 
to instruments 

e. Activate background configuration sets on 
instruments 

f. Generate reports 

7.6.6 SUPPORTED NASCOM AND USER ELEMENTS 

VDS instruments serve the following Nascom and 
user elements on GSFC: 

a. GSFC Technical Control/Comm Manager. 

b. GSFC Voice Control. 

c. Multi-Satellite Operation Control Center 
(MSOCC) . All POCCs associated with the MSOCC 
are currently supported by all three types of VDS 
instruments. POCC managers determine the 
type(s) of instrument(s) best suited to their needs. 

d. Other POCCs . The Hubble Space Telescope 
(HST) POCC is equipped with all three types of VDS 
instruments. The Extreme Ultraviolet Explorer 
(EUVE) is currently equipped with KS instruments. 

e. Flight Dynamics Facility (FDF) . The FDF is 
currently equipped with all three types of VDS 
instruments. 

f. Network Control Center . Fourteen 
instrument terminal blocks and 14 instruments 
were provided to the NCC. The NCC is responsible 
for connection to the VDS switch. 

g. Principal Investigators . The Information 
Processing Division (IPD), Building 23, is equipped 
with all three types of VDS instruments installed in 
the POCC Data Capture Rooms. 

h. Other Facilities . Buildings 5, 6, 7, 8, 21, 29, 
and 88 are equipped with all three types of VDS 
instruments. 


7.7 NASCOM POLICY ON DIGITAL VOICE 
TRANSMISSION 

7.7.1 BACKGROUND 

Over the years Nascom has developed an 
operational voice network renowned for the 
clarity of the delivered voice signal as heard in the 
listener's headset. Operationally, a principle 
feature of this high quality service is the near total 
absence of any “say again ..." being heard on the 
net. 

In 1991, Nascom conducted extensive testing of 
commercial off the shelf (COTS) multiplexers as 
part of its VAMS project (now canceled) and in 
preparation for a possible move of Nascom's voice 
service to the FTS2000 contract. Various algo- 
rithms (PCM, ADPCM, and proprietary) with A/D 
encoding for transmission at line rates from 64 
kb/s to 9.6 kb/s were employed. A key result of 
this test was that participants judged the voice 
quality to be less than that normally provided over 
a Nascom circuit when listening to a voice signal 
encoded for transmission at a line rate less than 32 
kb/s. As a result of this testing, the following poli- 
cy has been established. 

7.7.2 POLICY 

Nascom is inclined not to subject its network voice 
quality standards to possible degradation attrib- 
utable to voice signals that have been digitally en- 
coded for transmission at a line rate less than 32 
kb/s anywhere in their transmission path. Accord- 
ingly, it is Nascom policy that voice signals which 
are to be conferenced by Nascom systems should 
not have been digitally encoded for transmission 
at line rates less than 32 kb/s anywhere in their 
transmission path. Projects, programs or oper- 
ations which plan to interface to a Nascom voice 
conference loop any voice signal which has been 
digitally encoded for transmission at a line rate 
less than 32 kb/s anywhere in its path should ad- 
vise Nascom of all pertinent details as soon as such 
a plan becomes known. This advisory will enable 
Nascom to determine how best to deal with the 
proposed connection and to be ready with such 
measures as may be necessary to maintain the 
quality of the conference, inclusive of terminating 
service to the non-compliant interface. 
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b. Three-cabinet assemblies are provided at 
the Australian Earth Station, and the Buitrago 
Earth Station, Spain. A two-cabinet assembly is 
provided at the Cable & Wireless, Ltd. (CWL), Earth 
station on Bermuda. 

9.3.2.4 Remote Nascom Interface Facilities . The 
wideband terminal configuration at the Madrid 
NIF includes group band analog equipment for ex- 
tension of services to the DSCC as well as to the 
foreign-carrier Earth stations. This relay 
configuration provides regeneration at digital da- 
ta interfaces. The wideband terminals include 
their own cordless patching arrangement (matrix 
switching) and test facilities. In addition, there is 
TDM equipment associated with the wideband 
terminal. The terminals at the remote switching 
centers and NIFs are engineered, fabricated, in- 
stalled, and operated under NASA Communi- 
cations Division contract arrangements. 

9.3.3 WBDS INTERSWITCHING CENTER/NIF 
TRUNK AND STATION-UNIQUE CHANNEL 
CONFIGURATIONS 

These paragraphs describe certain unique wide- 
band channel configurations to individual GN and 
DSN complexes, and intercenter trunk channel 
configurations. 

9.3. 3.1 Canberra-JPL Trunk Configuration . Figure 
9-4 illustrates the configuration of the Canberra 
NIF-JPL wideband data trunks. One full-duplex 
1544-kb/s and one full-duplex 64-kb/s digital data 
trunk exist between Canberra NIF (located within 
the CDSCC) and JPL. The 1544-kb/s service is 
multiplexed as required by the DSN, using a 
TimePlex Link 2 + multiple aggregate multiplexer. 
Generally, there are three 32-kb/s voice, one 768- 
kb/s, one 256-kb/s, three 9.6-kb/s, one 1.2-kb/s, 
and seven 300-baud data channels configured. 

9.3.3.2 Madrid-JPL Trunk Configuration . Figure 
9-6 illustrates the Madrid NIF-JPL wideband data 
trunk configuration; this is similar in arrangement 
to the Canberra-JPL configuration, but the circuits 
are extended from the DSCC through the Madrid 
NIF, located a short distance away. The second 
wideband data trunk at Madrid is 56-kb/s, vice 64- 
kb/s (as at Canberra), and is routed through GSFC 
to JPL 

9.3.3.3 JPL-GSFC Trunk Configuration . Figure 9-7 
illustrates the JPL-GSFC wideband data trunk con- 
figuration. Six 56-kb/s wideband services exist be- 
tween GSFC and JPL. One is used to provide a Sta- 
tistical Multiplexer system between GSFC and JPL, 
one is used to extend the MDSCC 56-kb/s 


wideband to JPL, one is dedicated to TOPEX, two 
are dedicated to MARS Observer, leaving one for 
various multi-mission uses. Two 224-kb/s circuits 
are also provided, one dedicated to TOPEX and 
one for multi-mission support, including extension 
to the DSCCs for STS support. A 512-kb/s circuit 
provides a full-duplex interface between the GSFC 
MSS and the JPL EUG. 

9.3.3.4 GSFC-MIL/MIL-71 . Figure 9-8 illustrates the 
wideband data trunk configuration between GSFC 
and both MIL/MIL-71 and CCAFS, Building AE. 
Two 224-kb/s services - one full-duplex, and one 
simplex (MIL-GSFC) and two 56-kb/s services - both 
full-duplex are provided between GSFC and 
MIL/MIL-71 joint stations for GN service and STS. 
MIL-71 is supported by 56-kb/s and 224-kb/s full- 
duplex TDMS interfaces configured directly to JPL 
for DSN support requirements. A full-duplex 56- 
kb/s channel links Building AE to MIL/MIL-71. This 
circuit is used for support of both Delta and Cen- 
taur inertial guidance data. It is switched to GSFC 
via the MIL/GSFC full-duplex, 56-kb/s service. 

9.3.3.5 MIL-PDL Microwave Link . A government- 
furnished and installed microwave link is provided 
between the GN station on MIL and Ponce de Leon 
(PDL) for transmission of Shuttle launch phase da- 
ta. The system requires repeaters at Shiloh and 
North Wilson. The system is designed to carry du- 
plex 224/56-kb/s data and a six-channel duplex 
voice capability, plus a party line voice order wire. 

9.3.3.6 GSFC-BLT Trunk Configuration . Figure 9-9 
illustrates the wideband data trunk configuration 
between the Nascom Switching Center (Building 
14) and the Greenbelt Ground Network Station 
(BLT), which is housed at the Network Test and 
Training Facility (NTTF), Building 25. There is a 
central communications center in Building 25 that 
serves the in-house Network Development Center 
(NDC) and Simulation Operations Center (SOC). 
All wideband circuits are routed over government- 
owned cables that also use line drivers provided by 
Nascom. The following paragraphs describe the 
wideband data configuration of NDC and SOC. 

a. Network Development Center . All software 
programs are checked out at NDC. POCC progra ms 
are also checked out here. Three full-duplex, 
56-kb/s circuits plus a full-duplex, 1.544-Mb/s, a 
full-duplex 224-kb/s, and two 7.2-kb/s high-speed 
data circuits are provided between NDC and 
Nascom. These circuits can be either circuit 
switched or message switched to the GSFC users 
network or to the STDN. (The full-duplex 224-kb/s 
and 1.544-Mb/s circuits are shared with SOC.) 
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NOTES: 

The general channel configuration for the 512 KB/S data trunk is: 

(3) 32 KB/S voice, (1) 56 KB/S, (1) 224 KB/S, (1) 9.6 KB/S, and (1) 112 KB/S 

* The 64 KB/S data trunk is used as a backup for the 512 KB/S data trunk. 


LORAL 540/0!0-249m 
(as of February 1994) 


Figure 9-4 . Canberra NIF/JPL - Wideband Data Trunks 


Figure 9-5. 
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NOTES: 

The general channel configuration for the 51 2 KB/S data trunk is: 

(3) 32 KB/S voice, (1) 56 KB/S, (1) 224 KB/S, (1) 9.6 KB/S, and (1) 112 KB/S 

*The 56 KB/S data trunk is used as a backup for the 512 KB/S data trunk. loral swpimsow 

<UOfS+ptamb«r 1903) 


Figure 9-6. Madrid NIF/ GSFC Wideband Data Trunk Configuration 



NOTES: 

Numbers in parens (n) indicate quantity of channels 
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Figure 9-7. JPL / GSFC-Wideband Data Trunk Configuration 
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Figure 9-8. MIL /MIL-71 and CCAF5 Building AE / G5FC - Wideband Data Trunks 


b. Simulation Operations Center . The SOC is 
able to simulate either a spacecraft using the Ra- 
dio Frequency Simulation Operations Center (RF 
SOC), or a control center operation. It provides 
Portable Spacecraft Simulators (PSS) to the net- 
work to check out projects in the prelaunch phase. 
There are two full-duplex 224-kb/s circuits, one 
full-duplex 1.544-Mb/s circuit, and six voice circuits 
between SOC and Nascom for switching to either 
STDN or GSFC users. The full-duplex 224-kb/s and 
1.544-Mb/s circuits are shared with NDC. 

9.4 WBPS SWITCHING CONFIGURATION AND 
INTERFACES AT GSFC 

9.4.1 WIDEBAND SYSTEM SUPPORT TO STDN 

9.4.1.1 GN Support Interfaces . The WBDS circuit 
support between the GN and its users is essentially 
an automated message-switched Nascom service 
to local wideband interfaces at GSFC to/from the 
GSFC POCC's, the GSFC IPD facilities, GSFC FDF and 
the GSFC SOC. A major GN user is the JSC/MCC for 
the Shuttle missions. The JSC/MCC is also provided 
with a message-switched, wideband interface at 
GSFC with the GN and user POCC's. Channels for 
this interface are derived on the MDM-equipped 
BDS. Other GN users remotely located from GSFC 
are also message switched at GSFC. Finally, the 
NCCat GSFC is provided with a wideband message 
switched local interface. All of these interfaces are 
considered a part of the overall wideband system 
configuration. These wideband configurations 
supporting GN and its users are described in para- 
graphs 1 5.2 and 1 5.5. 

9.4.1.2 SN Support Interfaces . The WBDS circuit 
support between the SN and its users is principally 


provided via channels derived in the BDS and 
HDRS transport systems, direct to the SN major us- 
ers at GSFC, JSC, and MSFC. The HDRS provides di- 
rect broadcast wideband channel interfaces to the 
SN high data rate users at these three locations. 
Likewise, the BDS provides a broadcast WBDS de- 
rived channel interface configuration direct to and 
from GSFC and JSC. Local users at these locations 
are provided with circuit-switched access to and 
from the SN. At GSFC, Nascom provides its own 
circuit-switched access via its DMS. These systems 
and wideband configurations are described in 
paragraphs 5.3, 5.6, 5.7, and 15.4. 

9.4.2 WIDEBAND SYSTEM SUPPORT TO DSN 

The WBDS circuit support provided by Nascom be- 
tween the overseas DSN/DSCC's and its users are 
routed and circuit switched principally at JPL. 
These configurations are considered a part of the 
WBDS, and descriptions are provided in paragraph 
15.2. 

9.5 WBDS TIME DIVISION MULTIPLEXING 
APPLICATIONS 

9.5.1 TDM SYSTEMS OVERVIEW 

9.5. 1.1 Definition . TDM is a means of deriving a 
number of channels over a single path (i.e., the 
common carrier-provided wideband circuit) by 
dividing the path into time slots and assigning 
each channel its own intermittently repeated time 
slot. At the receiving end, each time-separated 
channel is reassembled. 

9. 5. 1.2 Nascom TDM Systems . In a technical sense, 
there are a number of Nascom systems that per- 
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Figure 9-10. Redundant Configuration of the KMRTS 
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b. The digitized (32 kb/s) voice channels are 
transmitted as four-wire circuits E and M type 1 
signaling interface. 

c. An external, leased communications circuit 
is provided by Nascom as an orderwire with var- 
ious drops at CD&SC, LCC, MIL, and MSFC buildings 
4207/4663. 

9.5.3.3 Nascom Support Arrangement . Nascom 
provides the following services to support KMRTS: 

a. Design and engineering, demarcation to 
demarcation. 

b. Implementation that includes circuit and 
equipment procurement. 

c. Installation. 

d. Testing. 

e. Sustaining engineering, depot level main- 
tenance, and system documentation. 

9.5.3.4 Planned Changes . Nascom will be convert- 
ing eligible existing circuits to GSA's FTS2000 Net- 
work A contractor starting in FY94. (See section 17 
for a description of Nascom's implementation of 
FTS2000 services.) Nascom intends to transition 
the voice circuits now transported by KMRTS to 
FTS2000. This action will release 736 kb/s of band- 
width (plus associated overhead) and should en- 
able a significant reduction to the circuit band- 
width that must be leased to transport these data 
links. By the end of FY94, Nascom plans to transi- 
tion the data circuits supported by KMRTS to 


FTS2000, where possible, and deactivate the 
KMRTS system. 

9.5.4 JSC-MSFC REDUNDANT TRANSMISSION 
SYSTEM 

9.5.4.1 Background . For support of STARLAB, the 
Air Force tasked NASA to procure and install an 
Encrypt For Transmission Only (EFTO), redundant, 
clear channel, 1.544 Mb/s data link between JSC 
and MSFC. The STARLAB project was experiencing 
so many slippages that NASA offered to install the 
system early, channelized for 52 voice and data cir- 
cuits to make maximum use of the bandwidth, and 
pay the difference between the STARLAB configu- 
ration and the NASA configuration. The request 
was approved, and the JMRTS was activated in 
June 1990. At the end of September 1990, the Air 
Force announced the cancellation of its STARLAB 
project. NASA was permitted to retain the JMRTS 
system as installed and configured. In view of 
STARLAB's cancellation, plans to provide for EFTO 
protection were terminated. JMRTS is now a 
Nascom system used for transport of operational 
voice, facsimile and data signals between JSC and 
MSFC. JMRTS is managed by Nascom in the same 
fashion in which similar systems wholly external to 
GSFC are managed by Nascom. A simplified block 
diagram of the JSC-MSFC Redundant Transmission 
System is shown in Figure 9-1 1. 

9 5.4.2 Configuration . The JMRTS provides JSC 
and MSFC with flexibility, limited only by channel 
cards and aggregate bandwidth, to configure a 
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Figure 9- 1 1. Simplified Block Diagram of the JSC-MSFC 
Redundant Transmission System 


data transport system on a mission-by-mission ba- 
sis without having to procure and turndown cir- 
cuits each time a requirement change is made. 
Though Nascom maintains overall hardware con- 
figuration control and oversight of the signals 
transported by any given channel, the arrange- 
ment enables MSFC and JSC to respond rapidly and 
effectively to requirements that fit JMRTS. To pro- 
vide this flexibility, the TDM's are channel-card 
configured to support the following: 

a. Voice . Forty four channels are available, 
each digitally encoded for transmission at a line 
speed of 32 kb/s using the CVSD algorithm. Ana- 
log facsimile is not supported on these channels. 

b. Asynchronous Data . None currently in use. 

c. Synchronous Data . Three channels are cur- 
rently configured and in use, one of which is allo- 
cated to the system diagnostics function. These 
channels are capable of supporting synchronous 
data and digital facsimile signals at clock rates up 


to 1154 kb/s. Currently, no facsimile signals are 
transported; the highest data rate used is 64 kb/s. 

d. Redundancy . Though the JMRTS "A" and 
“B" systems are configured identically in hard- 
ware, channel utilization on the two systems may 
vary. For example, channel 3 on the “A" system is 
assigned to the MSFC Stat Mux 13 composite; on 
System "8,“ channel 3 is assigned to MSFC Stat 
Mux 14's. 

9.5.4.3 Planned Changes . By the end of May, 
Nascom plans to transition all circuits currently 
transported by the JMRTS System to FTS2000. This 
will permit deactivation of two satellite 1.544 
Mbps circuits and the associated TDM equipment. 

9.5.5 LPS/KSC - MER/JSC - ROCKWELL/DOWNEY 
TRANSMISSION SYSTEM 

9.5.5. 1 General . Three distinct but closely inte- 
grated Nascom data links are employed to provide 
real-time transmission of Space Shuttle Orbiter 
launch operations information between the 
Launch Control Center/Launch Processing System 
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(LCC/LPS) at KSC, the Mission Evaluation Room 
(MER) at JSC, and the Rockwell International fa- 
cility at Downey, California, responsible for manu- 
facture and support of the Shuttle Orbiter Vehicle. 
Signals transported include synchronous and asyn- 
chronous data, isochronous (time independent) 
data, and voice. Functionally, these signals repre- 
sent the wideband Launch Processing System, 
main engine and orbiter downlink data streams, 
other high speed sensor and processed data sig- 
nals, and supporting operations voice loops and 
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audio circuits. This paragraph will describe the 
three data links in turn. An overview system dia- 
gram is provided in Figure 9-12. 

9.5.5.2 LPS/KSC - MER/JSC Data Link . This link em- 
ploys TDM-1258 time division multiplexers inter- 
faced to a DOMSAT-carried 2.048 Mb/s clear 
channel data circuit; the link provides signal trans- 
port between KSC's Launch Control Center and 
JSC's Mission Evaluation Room. Primarily, LPS 772 
kb/s data and shuttle related voice are transported 
via this link. Additionally, voice and data signals 
from Control Room 1 are handled. Voice and data 
signals are interfaced to appropriate channel cards 
on the TDM-1258. This link is shown in Figure 
9-13. 

9.5.5.3 KSC - Rockwell International Downey Data 
Link . Kennedy Space Center has established its 
Kennedy Integrated Data System (KIDS) using the 
Megamux Plus TDM and Megamux Transport 
Management System (MM/TMS) product line of 
General DataComm. This hardware provides KSC 
with the capability for easy integration and dis- 


tribution of multiplexed signals at T-1 rates, and 
provides access to Nascom data links without re- 
quiring Nascom to engineer and supply a multi- 
plexer each time a major data link is needed. Op- 
erating together, the MM/TMS and the Megamux 
Plus comprise an intelligent multiplexer node with 
automated network management features. Con- 
figuration management is under stored program 
control, but can be modified, within limits dictated 
by the aggregate bandwidth and the numbers and 
types of channel cards installed, by operator inter- 
action with the system via a mouse or keyboard. 
(See Figure 9-14.) 

9.5.5.3.1 Configuration. The KIDS provides the 
KSC-Rockwell Downey 1.544 Mb/s data link with 
flexibility, limited only by channel cards and ag- 
gregate bandwidth, to configure a data transport 
system on a mission-by-mission basis without hav- 
ing to procure and turndown circuits each time a 
requirement change is made. Though Nascom 
maintains overall hardware configuration control 
and oversight of the signals transported by any 
given channel, the arrangement enables KSC and 



Figure 9- 12. LPS - MER - Downey Wideband System 
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Figure 9- 13. Data Flow Routing K5C LCC/LPS - JSC MCC/MER 


Downey to respond rapidly and effectively to re- 
quirements that fit within KIDS. To provide this 
flexibility, the MM/TMS and MM/TDM’s are 
channel-card configured to support the following: 

a. Voice . Five channels are available, each 
digitally encoded for transmission at a line rate of 
32 kb/s using the ADPCM algorithm. 

b. Time Independent Data . Two channels are 
allocated for TID applications, one at 896 kb/s for 
transport of the same LPS data signal that JSC gets 
on its MER data link, and one at 224 kb/s to trans- 
port the 128/192 kb/s OD data stream. The TID 
channel provides a bandwidth-effective means of 
transporting isochronous data signals and other 
signals that are not synchronous with one of the 
standard clock rates supplied by the TDM. 

c. Synchronous and asynchronous data chan- 
nels are not currently configured on this link. 


9.5.5.4 JSC- Rockwell International Downey Data 
Link . This link employs TDM-1258 time division 
multiplex equipment interfaced to a DOMSAT- 
transported 576 kb/s clear channel data circuit be- 
tween JSC and Downey. The link currently pro- 
vides eight active channels for operations voice 
loops and circuits, and one asynchronous 19.2 
kb/s data beam circuit. Inactive, but still "in 
place", is a RED submultiplexer and associated en- 
cryption equipment that could interface to a 224 
kb/s synchronous channel on the link. Figure 9-15 
presents the configuration of this link. 

9.5. 5.5 Planned Changes . Nascom plans to 
transition the circuits on these systems to the 
FTS2000 backbone by October 1994. Whether the 
circuits between the Cape and Rockwell Downey 
are to be routed directly or through JSC remains to 
be determined. 


WIDEBAND DATA SYSTEM 9-18 




540-030 


DEMARC 



Figure 9-14* Kennedy - Downey (KIDS) Configuretion 
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Figure 9- 1 5. Data Flow Routing of the JSC / Downey Data Link 
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Fiaure 11-5. MDM - Common Carrier Configuration for Downlinking Data 

(Typical Site) 


11.4 MDM DATA SYSTEM 

Since the MDM Data System is provided with a de- 
tailed standalone description in paragraph 5.6, 
this section focuses on its role and capability in the 
BDS. 

11.4.1 ROLE OF THE BASELINE MDM DATA SUB- 
SYSTEM 

The Baseline MDM Data Subsystem is designed to 
effectively use the low rate wideband (up to 10 
Mb/s) digital transmission resource leased from 
the common carrier. The system creates discrete 
digital channels that time-share the total available 
digital bandwidth for high efficiency utilization of 
the system. The Baseline MDM Data System inter- 
faces the CCBTS at three separate locations. These 
locations are the NGT, GSFC, and JSC. The prime 
purpose of the NGT's MDM data system is to inter- 
face the CCBTS with the TDRSS ground terminal. 
The prime purpose of the GSFC and JSC MDM data 
systems is to interface the CCBTS with associated 


SN user spacecraft control centers and user data 
capture/processing facilities. 

11.4.2 BASELINE MDM DATA SUBSYSTEM CAPA- 
BILITY 

The Baseline MDM Data Subsystem consists of sep- 
arate data terminals at GSFC, NGT, and JSC. (See 
Figure 11-2.) Operationally, the baseline MDM sys- 
tem has the capability of 100 return link channels 
from NGT to GSFC, and 36 forward link channels 
from GSFC to NGT. The JSC station in the baseline 
MDM system may be operationally considered a 
"drop and insert" station. JSC can insert up to 30 
channels into the forward link and extract up to 20 
channels from the return link from NGT and GSFC. 
When this occurs, the total number of channels 
available for scheduling between NGT and GSFC is 
reduced by an equivalent number. 

The MUX/DEMUX systems and channel capacities 
provided by the MDMR Data System at the respec- 
tive locations are as follows: 
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a. GSFC: 

MUX (Broadcast) 

48 channels 

DEMUX (NGT/STGT) 

128 channels 

DEMUX (JSC) 

48 channels 

b. JSC: 

MUX (Broadcast) 

48 channels 

DEMUX (GSFC) 

48 channels 

DEMUX (NGT) 

48 channels 

c. GSFC/MSFC Trunk: 

MUX/DEMUX 

24 channels 
(duplex) 


The above channelization represents an upgrade 
to the original MDM Data System capabilities. All 
indicated MUX/DEMUX equipment will be pro- 
vided in redundancy. Connectivity is the same as 
per the original MDM Data System, except that 
spare DEMUX equipment lacking in the original 
MDM Data System has been added for each 
downlink at each location; also, a connectivity 
change has been implemented at the GSFC loca- 
tion wherein all receive channels from WSGT and 
JSC have been extended to the DMS in lieu of a 
channel termination sharing arrangement. 

11.4.2.1 Data Handling . At a functional level, the 
baseline MDM data system consists of separately 
located data terminals, each controlled by a collo- 
cated common control subsystem. The data termi- 
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nal controls the processing and distribution of da- 
ta signals to and from multiple user or network 
channels. Each data terminal consists of inter- 
faces, multiplexers, and demultiplexer equipment. 
The multiplexer equipment (see Figure 11-6) in- 
cludes an OC rack and multiple ITU racks. The OC 
performs the multiplexing of individual channels 
into a composite serial data stream for distribution 
to the CCBTS. The other features of the data han- 
dling operation are described in the following 
paragraphs: 

a. The demultiplexer equipment (see Figure 
11-7) includes an 1C rack and multiple OTU racks. 
The 1C performs the demultiplexing of the com- 
posite serial data streams from the CCBTS to indi- 
vidual data channels for the distribution of data to 
the appropriate user or network channel. 

b. Two sets of multiplexer and demultiplexer 
equipment are required for each data terminal. 
Each data terminal communicates with two sepa- 
rate distant-end data terminals. In addition to the 
two data terminals at NGT, there exists a third 10- 
channel data terminal to interface the NGT contin- 
gency, Line Outage Recording (LOR) playback 
equipment for discrete OTU channel playback to 
individual users. Additionally, the third data ter- 


minal provides a source of local test and spare 
equipment functions. 

c. A complete data string requires the mux of 
a source MDM data terminal and the demux of a 
destination MDM data terminal. Data is input to 
an ITU of a source multiplexer. On a time-division 
basis, the ITU output is transmitted to the OC and 
multiplexed into a composite data stream. The 
composite data is routed through the CCBTS to the 
demultiplexer of the destination MDM data termi- 
nal. The demultiplexer's 1C time division demulti- 
plexes the composite data stream and routes the 
data to an associated demultiplexer OTU. The 
OTU distributes the data to a specific user or net- 
work channel, completing the data string. 1C and 
OC equipment are provided with triple modular 
redundancy and two out of three Majority Voting 
Logic (MVL). ITU and OTU channel equipments are 
all similar modular units provided in a quantity 
that allows sufficient units to function as spares. 
1C and OC equipment are provided with common 
carrier modem clock and data, and are designed 
to operate at rates up to 10.0 Mb/s. The demulti- 
plexer provides a decoded composite data signal 
available on a patch basis to users who may wish 
to perform the demultiplexing function internally 
(e.g., JSC). ITU and OTU equipment are designed 
to operate at data rates up to 7 Mb/s. ITU's re- 
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Figure 11-6. MDM Data System Multiplexer Data Flow (Typical Site) 
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point-to-point or broadcast basis. The number 
and type of service capabilities available for each 
node is dependent on the quantity and type of 
line terminating equipment provided at the node. 
Data service terminating equipment is referred to 
as Group Interface Boards (GIB), and voice termi- 
nation services are referred to as D-3 channel 
banks (provided in 24-channel groups). A two- 
way point-to-point voice circuit occupies 128 kb/s 
of the throughput capacity. A two-way video con- 
ference occupies 3.088 Mb/s or 1.544 Mb/s of this 
capacity. Wideband services of 56-, 11 2-, 224-, 
448-, and 1,544-kb/s standard rates and variable 
rates between 56 kb/s and 15 Mb/s can be pro- 
vided with different types of data GIB's. Lower 
speed digital data (up to 9.6 kb/s) can be provided 
on TDMA voice channels which are comparable to 
leased alternate voice/data (AVD) services. Figure 
13-2 illustrates the nominal TDMA terminal con- 
figuration and interface capability. Each terminal 
is provided with patch panel facilities on both the 
common carrier and user interface sides. System 
users are responsible for the extension of circuits 
from their terminating facilities to the TDMA ter- 
minal back panel connectors. This link is the de- 
fined TDMA system interface. 

13.2 TDMA SYSTEM DESCRIPTION 

13.2.1 SYSTEM OVERVIEW 

The nucleus of the TDMA system is manufactured 
by Commercial Telecommunications Corporation 
(COMTEL), Santa Maria, CA. The TDMA Network 
services 13 locations in the continental U.S. with a 
mixture of voice, data, and compressed digitized 
video communication circuits described in para- 
graph 10.2.2.2. The TDMA station at the GSFC 
Nascom facility in Building 14, functions as the 
TCC. The TCC uses a computerized network con- 
trol facility manufactured by COMTEL to monitor 
and control the Nascom/TDMA system. This sys- 
tem is capable of supporting many traditional and 
advanced services. Nascom will operate and con- 
figure the TDMA system to fit current traffic de- 
mands until approximately 10/94. 

13.2.2 SYSTEM CONFIGURATION 

This paragraph describes the system configuration 
as a network structure of TDMA stations referred 
to as nodes. The configuration is illustrated in Fig- 
ure 13-3. 

13.2.2.1 Network Structure . The Nascom/TDMA 
Network System is a 15-node, fully interconnected 
satellite communications network that operates 
primarily in preassigned and dynamically reas- 
signed modes. The system is designed to be oper- 
ated and managed by a central network control 


computer, the TCC. Inherent capabilities of the 
TDMA system terminals permit distributed control 
in the absence of the TCC. The Nascom implemen- 
tation of the COMTEL TDMA system predomi- 
nantly puts to use its preassigned and reassigned 
Voice Frequency (VF) split-channel group interface 
capabilities through the addition of a Lynch model 
B325 type PCM channel bank. These same facilities 
are also used to implement high-speed (up to 9600 
b/s) data service when used with an external data 
modem. Also available are wideband group inter- 
faces that provide digital data services from 56 
kb/s to 15 Mb/s. Video services use a standard 
1.544-Mb/s wideband data channel for each video 
link and require the use of an externally supplied, 
compressed-video CODEC. 

13.2.2.2 Terminal Locations . Figure 13-4 shows 
the location of the fifteen system terminals or 
nodes and system node designations. The loca- 
tions of the GFE terminals and the establishment 
of common carrier owned and operated Earth sta- 
tions in proximity, dedicated to the Nascom/TDMA 
Network are as follows: 

a. NASA Field Centers: 

(1) Goddard Space Flight Center (GSFC) 
(Two Nodes). 

(2) Johnson Space Center (JSC). 

(3) Merritt Island T racking Station (MIL) 
(two nodes) 

(4) Marshall Space Flight Center (MSFC). 

(5) Jet Propulsion Laboratory (JPL). 

(6) Ames Research Center (ARC). 

(7) Langley Research Center (LaRC). 

b. Other Stations/Facilities: 

(1) Dryden Flight Research Facility (DFRF). 

(2) Goldstone DSCC (DSS-14). 

(3) Wallops Flight Facility (WFF). 

(4) Vandenberg AFB (VAFB). 

(5) White Sands NASA Ground Terminal 
(NGT). 

(6) Naval Auxiliary Landing Field (NALF). 
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total of 9 GIB slots at remote sites. At the remote 
sites, GIB slot #1 is dedicated to a DS1S-24 
GIB/voice channel bank. Slots 2 and 3 are ar- 
ranged for interchangeability between DS1S or 
VDR GIB. Slots 4-9 are normally assigned to data 
GIB's. The present GSFC GIB slot capacity is also 
nine. At GSFC, GIB slot #1 is assigned to the TCC, 
referred to as the NBC GIB. Slots 7 through 9 are 
arranged for interchangeability between DS1S or 
Data GIB's, with slot #9 currently dedicated to a 
DSIS/voice channel bank. Slots 2 through 6 are 
dedicated to data GIB's. 

13.2.3.2 Common Carrier Facilities . Implemen- 
tation of the common carrier facilities for the 
TDMA Network provides a full-period lease of a 
GTE 36-MHz, C-band, full-transponder service. Al- 
so provided by GTE and dedicated to this network, 
are 14 Earth stations collocated at the 14 desig- 
nated TDMA nodes. An intermediate frequency 
(IF at 70 MHz) interconnect facility extends to each 
TDMA terminal location. The common carrier fa- 
cility is specified to support at 15.556-Mb/s burst 
data service with a 1 x 10 -7 BER performance and a 
link availability of 99.5 percent or greater. 

13.2.3.3 User Interface . The Nascom-provided 
TDMA terminal is considered the demarcation 
point for all communications services furnished by 
this system. Unless otherwise provided by special 
exception or authorization, each local site in the 
TDMA Network is responsible for cabling and in- 
terconnection, and maintenance of such cabling 
and interconnecting facilities and customer equip- 
ment that are located on the customer side of the 
TDMA terminal demarcation point. 

13.3 TDMA SYSTEM OPERATION 

TDMA system operation is fully described in 
NASCOP, Volume III. Excerpts from this document 
are included here to round out the description of 
TDMA as a Nascom system. 

13.3.1 OVERVIEW OF TDMA SYSTEM OPERATION 

The Nascom/TDMA system consists of communica- 
tions equipment that accepts continuous voice, 
data, facsimile, and digitized compressed video 
signals from the end user terminal. The system 
converts signals into high-speed burst trans- 
missions to the satellite. The system also receives 
burst signals from the satellite, converts these sig- 
nals to the user's format, and delivers continuous 
data and voice channels to the local terrestrial in- 
terfaces. The other aspects of the system opera- 
tion are described in the following paragraphs: 


a. To accommodate the wide range of voice, 
data, facsimile, and video transmissions, modular 
GIB’s are used in the system. The GIB's process the 
user signals as digital information and then, by 
means of a modulator, convert the digital signals 
into analog signals suitable for transmission in the 
satellite. Conversion is accomplished by modulat- 
ing a 70-MHz baseband signal (which then be- 
comes the output of the TDMA system) to the 
Domsat upconverter equipment. 

b. Signals received from the satellite are fed 
from the downconverter to the system's demodu- 
lator. This signal is converted into digital informa- 
tion, which is then transferred to the voice and da- 
ta GIB's. 

c. The TDMA system is provided with test pan- 
els and patching capabilities necessary to substi- 
tute for malfunctioning components. Test and 
monitoring equipment is also provided to check 
for proper operating parameters and to allow iso- 
lation of malfunctions within the system. 

d. A monitor and control subsystem consisting 
of an HP-9826 desktop computer and a thermal 
printer, provides the operator with the capability 
to define and monitor various analog and digital 
points within the TDMA system. 

e. The TCC software provides ready access and 
displays for an operator to enter, edit, and store 
selected network parameters. The software per- 
forms limit checks and requires operator acknowl- 
edgment on selected operations to eliminate the 
possibility of inappropriate network and node pa- 
rameters and improper network operations. The 
software also provides the capability to systemati- 
cally distribute and command the execution of 
network parameters and BTP's generated from cir- 
cuit connectivity plans. 

13.3.2 AUTHORIZED CONNECTIVITY SERVICES 

Services accommodated on the TDMA Network are 
termed “authorized connectivity," which are 
those service requirements approved through for- 
malized internal Nascom procedures and selec- 
tively assigned to this element of Nascom trans- 
port resource and unique capability. It is intended 
that services on this system not be "dedicated," 
but preassigned and dynamically reassigned 
through scheduling using TCC capabilities. The 
system is scheduled for a weekly period no less 
than 48 hours in advance, and updated daily as 
needed, by the Nascom Network Scheduling 
Group (NNSG), based on requests from the NCC 
and/or other designated sources authorized to 
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schedule the approved services. (Refer to NASCOP 
Volume III.) 

13.3.3 TDMA SYSTEM MANAGEMENT 

TheTDMA Network is governed by a multi-faceted 
management system. Each level of management 
has separate and distinct responsibilities that fol- 
low the flow from review of communications re- 
quirements to implementation of circuit connec- 
tivity. 

13.3.3.1 Configuration Control . Configuration 
changes in the TDMA Network that affect the sys- 
tems of other organizations are to be processed 
through the CCB. Each proposed configuration 
change is evaluated in reference to: design, per- 
formance, cost, schedule, operational effective- 
ness, logistics, training, maintenance, and inter- 
faces with associated systems. Configuration 
responsibility assumed by Nascom Code 542 in- 
cludes all logical circuit connectivities as well as the 
physical GIB population and assigned addresses. 

13.3.3.2 Communications Manager . The NASA 
Communications Manager (COMMGR), Head, Op- 
erations Management Branch, or his designated 
representative, is responsible for management of 
the operation, maintenance, and scheduling of 
the TDMA Network system. The Head, Operations 
Management Branch is the authority for assign- 
ment of services on the TDMA Network. 

13.3.3.3 TDMA Control Center . All TDMA oper- 
ational activities are normally monitored and con- 
trolled by the TDMA control center, which is the 
Nascom/TDMA equipment at GSFC. The TCC pro- 
vides the following operational capabilities: 

a. Network and nodal parameters entry and 
editing. 

b. Network and nodal reconfiguration. 

c. Network connectivity planning. 

d. Network connectivity reconfiguration. 


e. Network troubleshooting and fault isola- 
tion. 

13.3.4 SYSTEM CAPACITY 

The modular architecture of the Nascom TDMA 
terminal permits each service center or node to be 
configured according to individual communica- 
tions needs. The TDMA system capacity is divided 
into three categories as follows: 

a. Design Capacity . This is established pri- 
marily bytheCOMTELTDMA system architecture. 

b. Wired Capacity . The TDMA terminals are 
prewired fora fixed channel capacity, which estab- 
lishes the extent to which the terminal hardware 
may be expanded without radical engineering 
change. 

c. Authorized Capacity . This is the capacity 
authorized by Nascom based on user require- 
ments, requests, and other considerations. 

1 3.3.5 TDMA PERFORMANCE STANDARDS 

Nascom/TDMA transmission parameters and inter- 
face considerations parallel those previously estab- 
lished and accepted by Nascom for its existing 
voice and data transmission facilities. Similarly, 
system service performance and availability should 
meet or exceed established Nascom parameters 
for comparable services as provided by traditional 
means. 

13.3.6 TDMA TRANSITION 

As the TDMA project draws to a close, a plan is be- 
ing developed for transitioning the connectivity 
provided by the TDMA system to new carriers. 
FTS2000 services provided by AT&T, under three 
contract modifications, have been contracted to 
meet the telecommunications requirements of 
Nascom. FTS2000 will be utilized to the degree 
possible to meet the requirements currently satis- 
fied by the Nascom TDMA system. Reference Sec- 
tion 17.4.9 for additional information in the 
FTS2000 implementation project. 
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Table 15-1 
DSN Station List 


LOCATION 

IDENTIFICATION / DSS 

ANTENNA DIAMETERS 
(meters) 

REMARKS 

GOLDSTONE, CA 
( GDSCC ) 


GCF-10 

— 

AREA COMM CENTER 


SPC-10 

— 

SIGNAL PROCESSING CENTER 

ECHO 

DSS- 12 

34 


VENUS 

DSS- 13 

34 

R&D STATION 

MARS 

DSS- 14 

1 70 



DSS- 15 

34 



DSS- 16 

26 



DSS- 17 

9 j 



DSS-24 

34 

FUTURE BWG (1993) 

CANBERRA, 
AUSTRALIA 
( CDSCC ) 


SPC-40 

— 

PROCESSING CENTER 

WEEMALA 

DSS-42 

34 

BALLIMA 

DSS-43 

70 


DSS-45 

34 

TIDBINBILLA 

DSS-46 

26 


DSS-34 

34 

FUTURE BWG (1994) 

MADRID, SPAIN 
( MDSCC ) 


SPC-60 

— 

PROCESSING CENTER 

ROBLEDO 

DSS-61 

34 

ROBLEDO 

DSS-63 

70 


DSS-65 

34 


DSS-66 

26 


DSS-54 

34 

FUTURE BWG (1994) 

MERRITT ISLAND, FL 


MIL-71 

9 

PRELAUNCH STATION 

PASADENA, CA 

NOCC 


— 

NETWORK OPERATIONS 
CONTROL CENTER 


GCF-20 

— 


CTA-21 

— 



(as of September 1992) 


BWG = Beam Waveguide 


DSCCs are located within latitudes of 45 degrees 
north or south of the equator. All DSCCs operate 
at S- band frequencies: 2110-2120 MHz for Earth- 
to-spacecraft transmission and 2290-2300 MHz for 
spacecraft-to-Earth transmission. All DSCCs are 
equipped with X-band downlink capability. 

b. Compatibility Test Area . CTA-21 at JPL has 
all the essential characteristics of the standard 
deep space stations adaptable to a 34- or 70-meter 
configuration except that CTA-21 has no tracking 
antenna. CTA-21 is used during spacecraft system 
tests to establish compatibility with the DSN of the 
proof test model and development models. CTA- 
21 has real-time data interfaces with the GCF-20 
communications center via voice and data commu- 
nications. CTA-21 is also used by mission oper- 
ations for DSN ground data system compatibility 
testing and training. Also available for use in 
ground data system compatibility testing is the 
Goddard Compatibility Test Van. 

c. Merritt Island Station . The DSN facility at 
STDN MIL is identified as MIL-71. This station pro- 


vides selected spacecraft telemetry and command 
capability during certain preflight testing at KSC. 
In addition, the facility is used for DSN compati- 
bility testing with the spacecraft to be supported 
by the DSN. 

15.2.1.2 Network Operations Control Center . 
The NOCC provides centralized operational and 
configuration control of the DSN and monitors 
and analyzes DSN real-time performance. The 
NOCC interfaces operationally with various deep 
space projects and their respective mission control 
and computing centers at JPL and Remote Mission 
Operations Centers (RMOC) located elsewhere. 
The Network Operations Control Area (NOCA), 
Network Data Processing Area (NDPA) and GCF-20 
of the NOCC are located in Building 230. The 
NOCC computers are not in series with the flow of 
data between the DSS and the JPL Mission Control 
and Computing Center (MCCC)/ RMOC, but rather 
the NOCC accepts a parallel feed of the DSS data. 
The NOCC electrical interface is with the GCF-20 
Central Communications Terminal (CCT). 
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15.2.1.3 Ground Communications Facility . The 
following paragraphs describe the GCF. 

a. GCF Capability . The GCF of the DSN pro- 
vides ground communications capabilities neces- 
sary for support of spaceflight operations. The 
GCF consists of long-haul leased circuits; terminal 
equipments; switching facilities; and personnel re- 
quired for the ground transmission, reception of 
data, recording, and control signals between the 
DSCCs, the NOCC, and the project mission control 
and data analysis locations (POCCs/RMOCs). 

b. GCF Design and Engineering . The GCF is de- 
signed and engineered to function as a multi- 
mission entity and is configured and operated to 
meet DSN and mission-dependent requirements. 
The DSN arranges with Nascom to provide all 
operational long-haul circuits and associated 
switching and data transmission facilities (refer to 
paragraph 15.2.5). The GCF is controlled by the 
GCF-20 CCT, a portion of which is allocated to, and 
functions as, the Nascom West Coast Switching 
Center (WCSC). The CCT is located at JPL in Build- 
ing 230 and includes communications terminal 
equipment, technical control, patch, test, switch- 
ing, and monitoring capabilities. 

c. Digital Communications Subsystem . This 
system in the JPL/GCF performs internal routing of 
data blocks in the CCT at JPL via the Error Correc- 
tion and Switching (ECS) computer and/or the 
CCP/EUG computers. 

15.2.2 JPL FLIGHT PROJECT SUPPORT OFFICE/ 
MCCC INTERFACE 

Using the MCCC at JPL, project personnel com- 
mand and control spacecraft in deep space and re- 
ceive telemetry and radio metric data via the DSN 
GCF. The facilities of the MCCC are organization- 
ally under the Flight Project Support Office (FPSO). 
Data flow interfaces also exist between MCCC and 
the TDRSS at White Sands, as well as between JSC 
and MCCC. TDRSS and STS interfaces will nomi- 
nally be via the Nascom WCSC at JPL. JPL also pro- 
vides management and support (tracking and data 
acquisition) for non-DSN space flight projects. This 
support is accomplished by the DSN 26-meter sta- 
tion or the TDRSS. The CCT accommodates both 
the DSN interface (GCF-20) and the Nascom WCSC 
interface to the MCCC, RMOCs, and RICs - as well 
as the WCSC interface with the WR launch facilities 
atVAFB. 

15.2.3 MISSIONS SUPPORTED ON THE DSN/GCF 

The DSN currently supports tracking and data ac- 
quisition operations related to Earth orbiting and 
deep space satellites. Table 15-2, SN Emergency 
Support Mission Set, Table 15-3, Deep Space Mis- 


sions, and Table 15-4, Cooperative and Near-Earth 
Mission Set summarize DSN support to these 
spacecraft. Task RTOP-60, Very Long Baseline 
Interferometry (VLBI) is also being supported. The 
DSN/GCF and its Nascom-furnished ground com- 
munications facility elements, described later in 
this document, have an ongoing support require- 
ment for these missions. Future DSN mission sup- 
port commitments and requirements are summa- 
rized in Appendix C. 

15.2.4 DEEP SPACE MISSION LOW RATE DIGITAL 
TELEVISION COVERAGE 

During the periods of encounter, landing, and on- 
surface activities, images are transmitted digitally 
on a real-time or delayed basis from the planetary 
spacecraft to the DSCCs. It is anticipated that dur- 
ing these periods, as was done for the Viking and 
Voyager-Jupiter/Saturn and other missions, 
Nascom will provide slow-scan TV channels (9.6 
k/bs) from JPL to NASA HQ, GSFC, and the cogni- 
zant research center for relay and distribution of 
processed image material to meet the high inter- 
est in events at that time. Requirements will be es- 
tablished for TV coverage of these phases during 
Mission encounters. 

1 5.2.5 NASCOM SUPPORT FOR DSN 

Nascom supports the DSN by providing dedicated 
circuits from each DSCCtothe JPL GCF. In addition 
to the Nascom support services described in para- 
graph 15.1.2, other Nascom-provided support ser- 
vices are described in the following subpara- 
graphs. 

15.2.5.1 Support for DSS's . DSCCs at Canberra, 
Australia, and Madrid, Spain, have real-time data 
interfaces with the Nascom Network and are con- 
nected with JPL's GCF-20 CCT via voice, TTY, and 
data communications facilities. The Goldstone 
GCF-10 communications center has TTY, voice, 
high-speed data, and wideband ties with GCF-20 
via two GEAM 1.544 MB/s T-1 systems, and one 
backup alternate voice/data circuit via Continental 
Telephone of California Company (CTCC) and 
PT&T facilities. From the GCF-10 communications 
center, the circuits are switched to the DSS's. The 
Goldstone communications capabilities are shown 
in Figure 15-2. Communications capabilities to Eu- 
rope and Australia are shown in Figures 15-3 and 
1 5-4 respectively. 

15.2.5.2 DSN Circuit-switched Network . All 
Nascom-provided data circuits used to support the 
DSN are circuit switched. Wideband and high- 
speed data channels are switched at Nascom 
switching centers and GSFC technical control by 
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Table 15-2 


SN Emergency Support Mission Set 


SPACECRAFT 

COMMAND RATE 
(kb/s) 

TELEMETRY RATE 
(kb/s) 

Landsat-4and 5 

.125 

1.0 Real -time 

24.0 Playback 

Shuttle 

32 or 72 

96, 192, 1024 

TDRS-1, 3, 4, 5, and 6 

.125 

2.0 

ERBS 

1.0 

1, 1.6, 12.8,32, 128 

HST 

1.0 

.5, 4,32,1024 

GRO 

.125 or 1.0 

1,32,512 

UARS 

.125 or 1.0 

1,32, 512 

EUVE 

2.0 

1,32,256,512, 1024 

TOPEX/Poseidon 

2.0 

16,512,768, 1024 


(as of February 1994) 


Table 1S-3 


Deep Space Missions 


SPACECRAFT 

COMMAND RATE 

TELEMETRY RATE 

International Cometary Explorer (ICE) 

256 b/s 

16,32,64, 128, 256 b/s 

Pioneer 6, 7 # 8 

1 b/s 

8, 16, 64,256, 512 b/s 

Pioneer 10, 11 

1 b/s 

16 to 1024 b/s 

Voyager 1, 2 

16 b/s 

40 b/s to 7.2 kb/s 

Magellan 

7.81 25 or 62.5 b/s 

40, 1200 b/s; 1 15.2, 268.8 kb/s 

Galileo 

32 b/s 

10 b/s to 134.4 kb/s 

Ulysses 

15.6 b/s 

64 b/s to 8.1 kb/s 

/ . _ r- _ i ■» r\n a \ 


(as of February 1994) 


Table 1S-4 

Cooperative and Near-Earth Mission Set 


SPACECRAFT 

COMMAND RATE 
(kb/s) 

TELEMETRY RATE 
(kb/s) 

Astro-D 

N/A 

1.024, 4.096, 32.768 Real-time 
262.144 Playback 

DSPSE 

1.0 

.125,-250, .5, 1, 2, 8, 64, 128 

GEOTAIL 

N/A 

16.4 or 65.5 Real-time 

65.5 or 131 Playback 

NIMBUS-7 

1.0 

4, 800 

SAMPEX 

2.0 

4, 16, 900 

Solar-A 

N/A 

1.024, 4.096, 32.768 Real-time 
131.072, 262.144 Playback 

i „ _ x r*i ..... , i nn a \ 


(as of February 1994) 
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patch panel facilities. JPL schedules Nascom cir- 
cuitry directly with Nascom on a weekly basis. 
There are limited message-switching requirements 
for DSN data routed through GSFC technical con- 
trol. The central communications terminal oper- 
ated by the DSN/GCF at JPL extends and distributes 


channels locally at JPL. The wideband data circuits 
are configured as shown in Figures 9-7 and 15-3. 

15.2.5.3 Nascom Monitoring Support . The data 
monitoring support provided by Nascom to DSN 
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Figure 15-2. GDSCC Communications Capabilities 
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Figure 1 5-20. GSFC Local and Remote User MSU Interface for 
GN/NCP-related Operations 
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multiple sources and this has conserved the num- 
ber of interfaces required in the MSU. 

f. Throughput Data Interfaces . With the ad- 
vent of throughput (4800 A block) data handling 
from the GN and the 26-meter sites, there has 
been a move away from multiplexed data inter- 
faces, to a greater number of discrete interfaces 
capable of handling only single-stream (non inter- 
leaved, single source at a time) data. Such inter- 
faces are usually dedicated to a respective mission 
and data type. The use of throughput data inter- 
faces has increased the required number of MSU 
dedicated interface requirements into the Control 
Centers (e.g., Multisat) and into the Sensor Data 
Processing Facility (e.g., the Telemetry Interface 
Preprocessor-into-TELOPS, or TIPIT), a throughput 
data handling facility. 

g. GN/SN Throughput Data Time-sharing of In- 
terfaces . Certain user throughput interfaces are 
time shared between the GN message switched 
sources and the SN source (i.e., the NGT/MDM sys- 
tem). The user interfaces are manually switched in 
theDMS fl.e., shifted between the MSU source, or 
an SN (MDM channel) source]. These transferable 
interfaces are identified in Figure 15-20. This 
transfer of sources is required for missions that are 
currently supported in a transition period, on both 
the GN (including the 26-meter Subnet) and the 
SN. 

15.5.6 OTHER MAJOR STDN USER INTERFACES AT 
GSFC 

Various other major STDN user and network sup- 
port facilities route their data via the MSU. This in- 
cludes the network scheduling and status data for 
the NCC, network and spacecraft checkout data to 
and from simulators, contractor locations, etc. 
However, the GSFC Flight Dynamics Facility inter- 
face with the MSU designed for handling metric 
data is unique. 

15.5.6.1 Flight Dynamics Facility Interface . The 
FDF interface (see Figure 15-21) is described in the 
following paragraphs: 

a. Data Received . The FDF receives orbital 
tracking data for spacecraft supported by the GN. 
The FDF also receives data from other NASA and 
DoD-ER and -WR trackers to provide launch and 
landing trajectory data for the STS and other mis- 
sions. FDF also receives Delta and Centaur launch 
vehicle guidance data from the GN and vectors 
from orbit computation facilities at other centers 
(i.e., JSC and JPL). Tracking data from the SN for 
spacecraft supported by the SN and for TDRSS 
spacecraft from the BRTS, are also received in the 
FDF. Additionally, the FDF receives BRTS telemetry 


data from WSGT, as it performs a housekeeping 
function for the BRTS. 

b. Data Generated and Transmitted . FDF func- 
tions include the generation and transmission of 
acquisition data to the GN and SN - and also the 
supply of scheduling aids to STDN controllers and 
the payload controllers using the GN and SN. It al- 
so transmits ephemeris data to its correspondents, 
vector data to other centers and networks, and 
BRTS scheduling requests and acquisition status 
data to the SN/NCC. 

c. Received Data Interface . Figure 15-21 illus- 
trates the complex interface that exists between 
the Nascom MSU and interfacing elements of the 
FDF, for the receipt and transmission of the various 
types of data. The following describes each FDF/ 
Nascom element interface. 

High-speed launch and landing trajectory data re- 
ceived on 2.4 kb/s circuits is routed through a 
Tracking Data Blocker, then to the MSU, and to 
the FDF over 224 and 56 kb/s lines for real-time 
processing. All data received by the Nascom MSS 
in 4800-bit blocks is delivered via the MSU 3760 
224-kb/s interface to the Nascom Interface Systems 
(NIS) elements of the FDF. These include high- 
speed Tracking Data Processor System (TDPS) data, 
launch vehicle guidance data, TDRS/BRTS tracking 
data, BRTS telemetry data. Intercenter Vector (ICV) 
data, and NCC scheduling data. 

d. Transmit Data Interface . On the transmit 
side (Figure 15-21), the FDF transmits acquisition 
data for the following: 

(1) Nonreal-time operations via 300-baud 
ASCII and TTY interfaces to the Nascom C-2100 sys- 
tem for store and forward distribution. 

(2) For real-time operations, the FDF inter- 
face also includes transmission of FDF-generated 
4800-bit blocks with implanted ASCII Coded TTY 
acquisition data messages, via 56 kb/s interfaces 
directly to the 3760 system from the NIS system. 

(3) FDF - generated 4800-bit blocks for SN 
operations are transferred via these same inter- 
faces to the MSU 3760 system , for routing to FDF 
correspondents. These include SN scheduling aids, 
SN acquisition data, BRTS scheduling requests, 
payload state vectors, and ICVs. 

15.5.6.2 Interbuilding Data Transmission System 
(IBDTS) . The IBDTS extends the Nascom wideband 
data systems locally at GSFC to major STDN data 
users. 

Figure 15-22 illustrates the IBDTS configuration. 
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Figure 15-22. Interbuilding Digital Transmission System Configuration (IBDT5) 


a. Original Building 23 System . The IBDTS #1 
is an original Nascom-provided GSFC local 
wideband data transport system installed in 1977 
to extend spacecraft sensor data, principally from 
the Nascom Wideband Data Tech Control Facility, 
in Building 14 to the SDPFs of the Information Pro- 
cessing Division (IPD) in Building 23. This system 
provides a DCE installation at each location capa- 
ble of operating 25 channels in each direction. 
The DCE equipment chassis were designed and fur- 
nished by Computrol Corporation. The transmis- 
sion medium for this system consists of 50 coaxial 
cables running 0.6 miles between the two build- 
ings. As designed, each channel is capable of in- 
dependently transmitting NRZ-L data and external 
clock signals at any rate up to 1.544 Mb/s. These 
are distributed at the distant end to local DTE de- 
signed to RS422/449 interface specifications. The 
DCE for each channel uses FM modulation of an 
8.5-MHz RF carrier to transmit simultaneous clock 
and data signals over a single interbuilding coaxial 
cable. The DCE can also supply internally gener- 
ated clock signals at standard rates of 7.2, 9.6, 56, 
224, 1344, and 1544 kb/s, when required, to user's 
DTE. 

b. Upgraded System . From 1983 to 1984, a 
number of original Computrol channel cards were 
replaced with new channel cards built by 
Astrotronic. Two of the channel cards and coaxial 
cables (selected for optimum characteristics), are 
used to support 2.0-Mb/s Spacelab data for exten- 
sion into the SLDPF in Building 23. Most channels 
of this system terminate spacecraft sensor telem- 


etry data into the TELOPS and TIPIT systems in 
Building 23. In Building 14, Room E171, the 
TELOPS channels are extended to the MSU and the 
TIPIT channels are extended to the DMS for net- 
work routing and configuration. 

c. Added Systems . Two additional IBDTS sys- 
tems have been provided by Nascom: 

(1) IBDTS #2, a four-channel system in- 
stalled in 1985 to Building 25, extends the SOC and 
the NDC over eight coaxial cables running approxi- 
mately 1 mile to Building 14. 

(2) IBDTS #3, a two-channel system in- 
stalled in 1986 to extend 1.544 Mb/s compressed 
video digital signals between the Nascom Building 
14 facility and the GSFC TV (video teleconferenc- 
ing) Center in Building 8, over four coaxial cables 
running approximately 0.3 miles. 

d. Transition of Channels . All IBDTS channels 
are expected to be transitioned to the 
Interbuilding Communication Link Upgrade (ICLU) 
by the end of calendar year 1 994. 

15.5.7 INTERBUILDING FIBER-OPTIC TRANSMIS- 
SION SYSTEMS AT GSFC 

15.5.7.1 Overview . Fiber-optic facilities support 
independent projects and systems requiring intra- 
and interbuilding transport fiber optics, which 
may be grouped and considered in two areas of 
distribution: 
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a. Facilities linking systems in the complex of 
Buildings 23 and/or 25 with Building 3/14. The 
link from Buildings 25 to 14 is approximately 
6000 ft 

b. Facilities linking systems within the Build- 
ings 13, 13A, and 13B complex and Building 14, 
which are related to ground system security en- 
hancements. 

The following identifies, in the order presented, 
these fiber optic-supported systems, their pur- 
pose, capabilities, and status. 

15.5.7.2 Interbuildina Fiber-Optic Facilities, 
Building 14 to Buildings 23 and 25 . An optical fi- 
ber system has been implemented between Build- 
ings 14 (Nascom Tech Control area) and 23 (Room 
C110) and between Building 14 and 25 (Comm 
Center, Room S172). Interbuilding ten-fiber cables 
support two independent systems. Two of the 10 
fibers are allocated in each cable to the 
Interbuilding Data Dissemination Resource 
(IBDDR) System, and eight fibers in each cable are 
allocated to a McDonnell Douglas (MDAC) fiber- 
optic system. The FO configuration is illustrated in 
Figure 15-23. 


15.5.7.3 Interbuildino Data Dissemination Re- 
source (IBDDR) System . This system was imple- 
mented to augment the IBDTS. Some existing and 
planned local GSFC wideband user interfaces have 
been transferred from the IBDTS to the IBDDR sys- 
tem. The IBDDR also anticipates future require- 
ments as they are being defined. The FO configu- 
ration is described as follows: 

a. For the IBDDR, Northern Telecom DMT-300 
fiber-optic terminals provide a T3 (44.736 Mb/s) 
digital transmission system, full duplex, using a 
fiber-optic FMT-45 transceiver over a cable pair 
between Building 14 and each of the two other 
building locations. This system provides 28 T1 
(1.544-Mb/s) channels to each of these locations. 
TwoTI channels in each of these systems are in use 
and are provided with Avanti Ultramux terminals, 
each of which submux 14 user channels that 
provide an aggregate composite at the T1 rate. 
The Ultra Mux channels provide RS-442/449 
interfaces for synchronous data rates from 2.4 kb/s 
to 512 kb/s in 800 b/s steps. Each system is also 
capable of 26 additional T1 bipolar user channels. 
When and if equipped with Avanti 2439H Local 
Area Data Distribution (LADD), each channel will 
support a 1.544-Mb/s RS-422/449 user interface. 


BUILDING 23 ROOM Cl 10 


BUILDING 25 COMMCENTER ROOM SI 72 



OPTICAL 

FIBERS 

(SIECOR) 


10 


OPTICAL 
FIBERS 
( SIECOR ) 


BUILDING 14 NASCOM TECH CONTROL 



NOTE : 1. THE MDAC UNITS ARE COLLOCATED WITHIN THE SAME RACK. 
2. THE IBDDR IS IN TWO RACKS. 


540 / 010-061 

(as of September 1990) 


Figure 15-23. Interbuilding Fiber Optic Facility Configuration 
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These configurations therefore are capable of up 
to 54 possible user channels. 

b. Overall system configuration (data rates, 
number of channels, and channel connections) is 
controlled and monitored by the Building 14 
Nascom technical control operator, who controls 
channel assignments from a local control terminal. 
Once the system configuration is established, data 
transfers between users are processed and routed 
automatically. During normal operation, system 
status messages and modification commands are 
exchanged among the terminals in a manner com- 
pletely transparent to the users. For maintenance 
purposes, the fiber-optic terminals at Buildings 23 
and 25 may be configured locally by connecting a 
terminal directly to the equipment cabinet. 

c. All channels of the IBDDR system are cur- 
rently assigned. Any changes in requirements for 
IBDDR service are coordinated through Code 
542.1. 

d. Transition of Channels . All IBDDR channels 
are expected to be transitioned to the 
Interbuilding Communication Link Upgrade (ICLU) 
by the end of calendar year 1994. 

15.5.7.4 McDonnell Douglas (MDAC) Fiber Optic 
System . The MDAC fiber-optic communications 
system also connects Buildings 25 and 23 with 
Building 14. The system provides four full-duplex 
fiber-optic paths: one prime, one backup, and two 
unused. The implemented link is capable of op- 
erating at up to 100 Mb/s. The system has been re- 
configured by adjusting two links to operate at 96 
Mb/s. The system has been provided for test and 
development purposes and for possible applica- 
tion for high data rate requirements leading into 
the Space Station era. One utilization transmits 
HDDR data tapes electronically from Building 25 
via Building 14 to the SLDPF in Building 23 at 48 
Mb/s. The user has implemented a Model 736 Rate 
Converter Unit necessary for this application. Al- 
though in use, the 96-Mb/s link has not yet been 
fully accepted as operational. 

15.5.7.5 MODNET System . Fiber optic cables are 
installed within and between Buildings 3/14, 23, 
and 28 to support a backbone (interbuilding) FDDI 
ring, a local (intrabuilding) FDDI ring, and four 
interbuilding HYPERchannel trunks. 

Fiber optic connectivity will soon be provided to 
Building 2 in support of Code 510's SPOF and XTE, 
to Building 25 in support of Code 510's Simulation 
Operations Center (SOC), and to Buildings 20 and 
29 in support of XTE. 

15.5.7.6 Buildings 13 and 14 Complex Fiber Op- 
tics . Several systems are related to the enhanced 
security development in the Building 13/1 3 A/ 


13B/14 complex serving the NCC and Nascom sys- 
tems. Elements of these systems include the fol- 
lowing: 

a. MSU/CSS-Related Security Enhancement . 
This system provides a fiber-optic link at 56 kb/s 
between the NCC (Building 13, Room 141) and the 
MSU/CSS Distribution Bay (Building 14, Room 
E-171). Presently established and operational are 
fiber-optic multiplexed TTY links between the 
MSU/CSS rack and the Building 13B cryptographic 
area, for transmission of advanced schedules for 
the Space Network (TDRSS) ground systems. Also 
implemented are internal CSS-related Nascom 
links between: (1) the Communications Terminal 
Modular Controller (CTMC) interface and the Op- 
erator Interface Console, (2) the MSU/CSS and the 
DMS Control System, and (3) the MSU/CSS and the 
MACS. In addition, secured voice links have been 
implemented between the technical control group 
(Room E-171) and the Building 13 complex. 

b. Building 13 Complex Fiber Optic Distribu- 
tion System . This system provides a fiber-optic 
distribution system between Building 14 and the 
Building 13 complex, and distribution within the 
Building 13 complex. The FO configuration is illus- 
trated in Figure 15-24. The system was imple- 
mented in two parts: part one for the installation 
of the fiber-optic cables; part two for the installa- 
tion of the fiber-optic/copper conversion, patch, 
test, and interface systems. Passive Fiber-Optic 
Racks (PFOR) and the interconnecting fiber-optic 
cables between the PFORs are included in the 
baseline system. The installation specifies the use 
of 50/125 pm fiber cable type with bulkhead feed 
through SMA-type connector termination. In the 
fiber-optic link between Buildings 14 and 13, 
transmit/receive circuits are implemented using 
duplex fiber cables. Forty-eight duplex cables are 
provided for interbuilding service. The RS-422 
copper-to-optical receiver/driver units (0-5 Mb/s) 
are used for the interface to user equipment, if re- 
quired. 

c. Building 13 PFOR Installation . Additional 
PFORs in Buildings 13A and 13B and the Building 
13 PFOR form a three-node configuration inter- 
connected by 12-fiber cable links. Each PFOR is 
provided with both Black and Red separate user 
interfaces. 

15.5.8 MODNET AND NOLAN 

15.5.8.1 Background . The MO&DSD Oper- 
ational/Development Network (MODNET) pro- 
vides a unified Directorate-wide operational net- 
work linking various operational MO&DSD com- 
puters using Transmission Control Proto- 
col/Internet Protocol (TCP/IP) and HYPERchannel 
protocol. Nascom Code 541.2 is responsible for 
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Figure 15-24. Building 13 Complex Fiber Optic Distribution System Configuration 


network expansion, network security, continuing 
engineering, maintenance and operation of 
MODNET. 

MODNET has been an operational network since 
1988. Various processed orbit, attitude, and te- 
lemetry data are transported between more than 
50 host computer systems via MODNET. There is 
no direct interface between MODNET and any oth- 
er Nascom Network. 

15.5.8.2 NOLAN. Expanding MODNET Beyond 
Code 500 Systems . MODNET is being expanded to 
connect non-MO&DSD computers through the 
Nascom Operational LAN (NOLAN). NOLAN pro- 
vides an operational FDDI LAN on-center and a 
wide area network (WAN) capability for off-center 
data transport. Given formal requests for service, 
expansion of connectivity to new or additional 
buildings on GSFC for support of non-MO&DSD 
host systems will be considered for implementa- 
tion through NOLAN. Formal requests for connec- 
tion have been received from the projects listed in 
Table 15-5. 

15.5.8.3 System Configuration . The HYPER- 
channel portion of MODNET is shown in Figure 


15-25. The IP portion of MODNET/NOLAN is 
shown in Figure 15-25a. MODNET consists of a 
Backbone FDDI ring connecting Buildings 23, 28, 
and 3/14. Redundant concentrators connect dual 
homed IP and HYPERchannel routers to the FDDI 
Backbone. The IP routers provide an interface to 
local ethernets, local FDDI rings, and serial links to 
WAN connections. The HYPERchannel routers pro- 
vide a proprietary interface to hosts utilizing 
NETEX/BFX. Though the IP and HYPERchannel 
networks both utilize the same FDDI Backbone, 
there is no gateway connection between the two 
networks. 

The HYPERchannel network also consists of coaxial 
cable that supports 50 Mbps trunks connecting the 
HYPERchannel-DX adapters and the older A-series 
HYPERchannel adapters. There are two Highway 
trunks that run between and within Buildings 3/14 
and 23, two Highway trunks that run between and 
within Buildings 3/14 and 28, two local trunks in 
Building 3/14 (MODLAN) that serve Code 510 
hosts, and two local trunks in Building 23 
(InfoLAN) that serve Code 560 hosts. 

Two real-time network monitoring systems sup- 
port MODNET. The HYPERchannel NMS4, running 
proprietary NSC software, is located in Building 23 
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Room E314 in the DDF area. The IP NMS, running 
HPOpenView, is located in Building 14 Room E171 
in the Technical Control area. Both monitors pro- 
vide a graphical and analytical indication of the 
health of MODNET. 

15.5.8.4 MODNET HYPERchannel Connections . 
Network Systems Corporation Network Executive 
(NETEX) is the common network operating system 
forthe MODNET. Bulk File Transfer (BFX) software 
and User Access software are utilities that allow 
file transfers between hosts. They are not Govern- 
ment Open System Interconnection Profile 
(GOSIP)-compliant protocols. 

The following systems are connected to the 


quirement for a gateway between TCP/IP and 
NETEX, none will be provided. 

The following systems are connected to MODNET 
using IP: 


MODNET: 


Code 510 

CMS 1,2 

Code 510 

DOCS 1.2 

Code 510 

MODGW 
1. 2 

Code 510 

SPIF 1, 2 

Code 510 

API-8 

Code 520 

DSTL 
85, 86 

Code 520 

ALF 

Code 550 

FDF 3, 4, 

Code 560 

IPDGW1, 2 

Code 560 

IPDOMS 

1&2 

Code 560 

SIPS A, B,C 

Code 560 

UNIS 2200 

Code 560 

UARS 1,2 


Code 560 TDMLZP 
1&2 


Code 560 ISTP1-4 


Command Management 
System 

Data Operations Control 
System 

MODLAN Gateway pro- 
vides isolation to the 
MSOCC MODLAN trunks 

Shuttle/POCC Interface 
Facility 

Applications Processor 

Data Systems Technol- 
ogy Laboratory 

MicroVAX II Research 
Workstation 

Flight Dynamics Facility 
InfoLAN Gateway 
Mass Storage System 

Spacelab Data Process- 
ing Facility, Input 
Processor System 

Telemetry 

Facility 

Upper Atmosphere 
Research Satellite Cen- 
tral Data Handling 
Facility 

Time Division Multiplex 
Level Zero Processor. 
Upgrade to Telemetry 
Online Processing 
System 

International Solar Ter- 
restrial Physics Program 


Code 510 TPOCC LAN 

Code 513 TOMS-EP 

Code 520 FAST LZP 
Code 550 FDF 
Code 560 PACORII 
Code 560 DDF II 


Transportable Payload Op- 
erations Control Center Lo- 
cal Area Network 

Total Ozone Mapping 
Spectrometer - Earth Probe 

Level Zero Processor 

Flight Dynamics Facility 

Packet Processor 

Data Distribution Facility 


15.6 SPACE SHUTTLE PROGRAM NETWORK SUP- 
PORT 


15.6.1 SPACE SHUTTLE PROGRAM SUPPORT OVER- 
VIEW 

The forms of support provided by the STDN 
Ground and Space Networks and by many other 
special Space Shuttle supporting ground stations, 
including the Nascom special support arrange- 
ment with the Space Shuttle Program (SSP), are de- 
scribed in this paragraph. It should be mentioned 
that GSFC, Code 500 has the responsibility to act as 
the "lead range" forthe SSP, i.e., to arrange all of 
the T&DA support required by JSC for the SSP. 
Nascom provides most of the operational commu- 
nication interconnections as part of that respon- 
sibility. The Space Shuttle Program is conducted 
by JSC using the launch facilities at KSC. Tracking 
stations operated by ER, VAFB, WR, WSMR, United 
States Army Electronic Proving Ground (USAEPG), 
DFRF, GSFC managed ground stations, and JPL DSN 
provide T&DA functions to the Shuttle. In addi- 
tion, several stations and facilities of the DOD, var- 
ious off-net remote sites and contractor locations 
are used. 

15.6.2 STDN GN SUPPORT FOR SSP 

The communications support provided or spon- 
sored by GSFC via the STDN/ground stations for 
Space Shuttle operations is described in the fol- 
lowing paragraphs: 


15.5.8.5 MODNET IP Connections . TCP/IP has 
been selected for use as users migrate to GOSIP- 
compliant protocols. TCP/IP is used on both 
MODNET and NOLAN. As there is currently no re- 
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Figure 15-25a. MODNET/NOLAN System Diagram 





















Table 15-5. NOLAN Connections 
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Data Volume (Maximum) 

5 Gbits/day 

TBD 

TBD 

38 Kbps 

9.6 Kbps 

Real-time: 1 Kbps 
Production: 5 Mbps 
Opns control: 1 Mbps 

TBD 

TBD 

TBD 

TBD 

60 Mbps per day 

TBD 

TBD 

o 

CD 

1- 

TBD 

i 

i 

8 

November 

1993 

November 

1993 

February 

1994 

February 

1994 

February 

1994 

March 1994 

April 1994 

May 1994 

May 1994 

May 1994 

June 1994 

TBD 

TBD 

091 

TBD 

Location of Hosts 
or Workstations 

Berkeley, CA 

Building 3 

Building 25, 
Room N171 

Building 29, 
Room 150 

8 

f! 

il 

Building 2, 
Room W20 

Poker Flats, 
Alaska 

San Diego, CA 

Boston, MA 

Building 7/10 
Building 5 
Building 12 

Boston, MA 

Baltimore, MD 

Building 22, 
Room TBD 

TBD 

TBD 

li 

li 

CM 

CM 

i 

CO 


CM 

8 

i 

O 

CM 

TBD 

TBD 

TBD 

TBD 

TBD 

TBD 

TBD 

TBD 

Bandwidth 

(Mbps, 

Maximum) 

1.536 

o 

o 

o 

O 

T— 

o 

.0096 

.056 

.056 

o 

T— 

.224 

1.536 

o 

TBD 

TBD 

Protocol 

TCP/IP 

TCP/IP 

TCP/IP 

TCP/IP 

TCP/IP 

TCP/IP 

TCP/IP 

TCP/IP 

TCP/IP 

TCP/IP 

TBD 

TCP/IP 

TCP/IP 

TBD 

TBD 

j* 

c 

3 

i 

Berkeley: V.35 
GSFC: RS422 

Ethernet 

Ethernet 

Ethernet 

Ethernet 

3 Ethernets 

RS-232 

RS422 

RS422 

Ethernet 

RS422 

RS422 (multiple) 

Ethernet 

091 

TBD 

h 

f 1 

S 

FAST/ 

Berkeley, CA 

SOHO ECS 

SOHO 

XTE 

XTE 

XTE 

FAST/Poker 
Flats, Alaska 

XTE 

XTE 

Nascom 

SWAS 

HST 

Clementine 

Landsat7 

TRMM 
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Table 16-1. TDRSS - Supported Missions Planned (Note 1) (Cont'd) 
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ON-ORBIT MAXIMUM DATA RATES (KB/S) BY SERVICE TYPE j 

KSA RTN 
(Note 2) 

a 

I|ii 

fJL: 8 

300 

MB/s 





- 



- 

13) 

2, 4, 32, 
48 MB/s 
or (4] 



oj « 

£2<o2 “ 

'".a ° 

CM ^ 

50 

MB/s 


o 

2<0 

> 



SSA RTN 

o 


6.0 

(RT) 

300 

(PB) 

MNI} 

TBD 


192 

{12} 

v> ^ 



512, 

1024 

(PB) 

- 


6.0 
(RT) 
300 
(PB) 
(1.2 C 

TBD 


192 

{12} 

CNjH 

rj(T 



sfs 

MA RTN 

o 


11.5 

1-10 

OONS) 






32,48 
or 64 
(PB) 

- 


in 

1-10 
(2 BALL 






CM ►— £7 

en ocSi 

SSA/KSA 

FWD 

a 

OOOd 


TBD 

oo 

—•COLL Q 


RNG 

OO 

OO 

"18 

RNG 

- 

Mi C 
POCC 

11.5 

{1.44 

OMNI) 

TBD 

15] 

1.6 

MSFC 

POCC 

S e 

iqS 

OOOd 

mUc 

POCC 

P S 

SMA FWD 

o 



TBD 






RNG 

- 


CM 

TBD 






P £ 

SUPPORT 

PERIOD/ 

ORBIT 

14 DAYS 
28.5 DEG 
296 KM 

5 YEARS 
705+/-5 KM 

10-90 DAYS (EACH) 
78 DEG SOUTH 
(W-5) 

40 KM 

16 DAYS 
ORBIT TBD 

TBD 

51 .6 DEG 
352-407 KM 
CIRCULAR 

3 YEARS 
35 DEG 
350 KM 
CIRCULAR 

16 DAYS 
28.5 DEG 
296 KM 

14 DAYS 
28.5 DEG 
296 KM 

2-5 YEARS 
23 DEG 
600 KM 

LAUNCH 
VEHICLE/ 
SITE/DATE 
LANDING SITE 

5 

o 

CO 

Y 

to 

*9 

CO 

t- 

co 

DELTA II VAFB 1/98 

BALLOONS FROM 
MCMURDO 12/94 

STS-76 KSC 2/96 
TBD 

(LAUNCH VEHICLE, 
LAUNCH SITE, AND 
LANDING SITE - TBD 
FOR ALL LAUNCHES 

5/97, 6/97, 7/97, 8/97, 
10/97, 1/98, 6/99, 2/1, 
5/1, 8/1, 9/1, 10/1 

7/97,9/97, 10/97, 11/97, 
12/97, 4/98, 7/98, 10/98. 
1/99, 4/99, 7/99, 1/1, 

4/1, 7/1 

10/99, 1/00, 10/00 
4/00,7/00 

H-ll 

TANEGESHIMA, JPN 
8/97 

STS-73 KSC 9/95 
EAFB 

STS-62 KSC 3/94 
STS-75 KSC 12/95 
STS-81 KSC 9/96 
STS-88 KSC 7/97 

DELTA II ER 8/95 

MISSION TITLE 
(APPROVAL STATUS) 
DOCUMENTATION 

SPACELAB INTERNATIONAL MICROGRAVITY 
LABORATORY MISSION -2 

STS IML-2 PIP 
NSTS-(TBS) 

LANDSAT-7 

(APPROVED) 

LANDSAT-7 DMR, SDR DRAFT, 11/93 

LONG DURATION BALLOON 

PROGRAM 

(APPROVED) 

LDB SIRD, REV 1 (5/91) 

SPACELAB LIFE SCIENCES - 3 
SLS-3 (TBD) PIP 

SPACE STATION (ALPHA) 

ALPHA STATION - ADDENDUM TO PIP (1 1/93) 

RUSSIA AS THE PRIMARY DEVELOPER 
U,S. AS THE PRIMARY DEVELOPER 

JAPAN AS THE PRIMARY DEVELOPER 

EUROPEAN SPACE AGENCY AS THE PRIMARY 
DEVELOPER 

TROPICAL RAINFALL MEASURING MISSION 

TRMM MRR (1/93) 

TRMM DMR (12/93) 

SPACELAB UNITED STATES MICROGRAVITY 
LABORATORY (APPROVED) 

STS USML-2 PIP 

JSC-21 1 15. BASIC (9/91) THRU CHANGE NO. 13 

SPACELAB UNITED STATES MICROGRAVITY 

PAYLOAD 

(APPROVED) 

STS USMP-2 PIP 

NSTS-21 182, BASIC (6/93) THRU CHANGE NO. 1 

X-RAY TIMING EXPLORER 
XTE DMR (9/93) 

MISSION 

(ACRONYM) 

IML-2 

(SPACELAB) 

LANDSAT-7 

LDBP 

(SERIES) 

SLS-3 

(ALPHA) 
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b. Video/ Analog Service Support . As indicated 
in Figure 16-4, the Spacelab video and analog sig- 
nals are backfed to Nascom technical control at 
GSFC, Building 14, for fault isolation purposes. 

The video is also monitored, quality checked, and 
distributed locally in the Building 8 Nascom TV 
control facility. 

c. MOM and SM Support . Nascom is respon- 
sible for MDM and SM equipment engineering, 16.2.5.2 DELETED 
configuration, control, and logistics support, and 

for assuring that the equipment is operated in a 
manner that meets all performance specifications. 

16.2.5 DELETED 

16.2.5.1 DELETED 


Figure 16-7. DELETED 
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16.2.6 HUBBLE SPACE TELESCOPE 

16.2.6.1 HST Mission Description . Hubble Space 
Telescope (HST) is a high-resolution optical tele- 
scope operated as a national facility. It consists of 
a 2.4-meter aperture Ritchey-Chretien cassegrain 
telescope weighing approximately 9525 kg - with 
various energy detectors designed for the observa- 
tion of infrared, visible, and ultraviolet wave- 
lengths (0.12 to 1000 microns). HST was launched 
by the Space Shuttle from KSC on 24 April 1990, 
and deployed into a 28.5-degree inclination, cir- 
cular orbit that permits an HST orbit lifetime of 15 
years. HST is projected for 15 years in-orbit opera- 
tion. HST servicing/maintenance missions are 
manifested on the Space Transportation System 
(STS) every 3 years (approximate) after launch. 

a. Spacecraft Data Flow . The data flow be- 
tween the HST spacecraft and the HST ground fa- 
cilities is described in the following paragraphs: 

(1) All of the HST observatory science and 
engineering data received via TDRSS/Nascom is 
routed to the POCC and the GSFC Data Capture Fa- 
cility. The DCF records all of the science data. This 
data is forwarded to the Science Institute Space 
Telescope (Sd) within 1 day. 

(2) The POCC receives, records, processes, 
and displays all HST engineering data to monitor 
the health and safety of the science instruments 
and support systems. It also receives and transmits 
the science data to the Science Support Center 
(SSQ and the Sd for quicklook evaluation and tar- 
get acquisition support. The POCC also generates, 
transmits, verifies, and records all commands to 
the HST and produces the daily mission schedule. 
Either the SSC or the Sd may transmit (not simulta- 
neously) real-time HST command requests, as 
scheduled to the POCC via the SSC command inter- 
face. 

b. TDRSS Support Services . The TDRSS provides 
approximately 320 minutes-per-day support on 
the SSA return link and 100 percent in-view sup- 
port on the MA return link. All HST support is pro- 
vided by TDRSS. DSN/GN is responsible for provid- 
ing contingency support for the HST if TDRSS or SC 
failure prevents communications via that link. MA 
return services provides real-time science or engi- 
neering data at up to 4 kb/s on l-channel, and real- 
time engineering data up to 32 kb/s on Q-channel 
(on MA/SSA cross support when needed). SSA re- 
turn link service on l-channel provides data at 
1.024 Mb/s for real-time science, or engineering 
and science data playbacks, or for Onboard Com- 
puter (OBC) memory dumps. 


16.2.6.2 Space Telescope Observatory Manage- 
ment System . The HST Observatory Management 
System (STOMS) consists of the HST Operations 
Control Center (STOCC), and the Data Capture Fa- 
cility (DCF). 

a. HST Operations Control Center . The STOCC 
located in Building 3/14 areas at GSFC, and com- 
posed of the POCC and the Science Support Center 
(SSC), serves as the focal point of all orbital oper- 
ations, including the monitoring and support of 
the spacecraft. The following describes the com- 
ponents of STOCC: 

(1) The HST POCC performs all real-time 
health and status functions and offline spacecraft 
support functions for the HST mission. The HST 
POCC is composed of the Preliminary Operations 
Requirements and Test Support Section (PORTS), 
the POCC Applications Software Support (PASS), 
and the UPS. 

(2) PORTS is that part of the HST POCC re- 
sponsible for engineering design, hardware, on- 
line computer system payload operations, telem- 
etry processing, and supporting functions. In- 
cluded are a High Rate Switch, two Telemetry and 
Command Processors (TAC), three Applications 
Processors (AP), and two Virtual Interface Proces- 
sors (VIP). The TAC's and VIP's are DEC PDP- 
11 /44's. The AP's are DEC VAX 4000 computers. All 
external communications are through the high 
rate switch. 

(3) PASS is a collection of software systems 
responsible for implementing capabilities in the 
POCC offline computer system as provided 
through PORTS. PASS responsibilities include 
areas of mission scheduling, command loading, at- 
titude and calibration computation, spacecraft 
subsystem monitoring, PASS data management, 
and PASS operations support. 

(4) Support and Maintenance System 
(SAMS) is a separate facility located in Building 1 
that provides resources for the development and 
staging of hardware, software, and network 
changes on a non-interference basis with the HST 
POCC. SAMS will also have the capability to serve 
as an emergency backup control center in the 
event of a requirement to evacuate the POCC fa- 
cilities in Building 3/14. 

(5) UPS is an intelligent terminal in the 
POCC that provides an NCC interface for schedul- 
ing tracking, telemetry, and command support via 
the TDRSS. 

b. Data Capture Facility . The DCF is a GSFC- 
managed and -operated element responsible for 
the capture and quality accounting of all received 
HST science data. It is a dedicated element of the 
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(b) The DDCS at GSFC is required to 
support: 

1. A peak throughput of 107 packets 
per second from the PACOR to the IGSE's. 

2. A peak throughput of 65 packets per 
second between the CMS and the IGSE's. 

3. Variable packet sizes: 16, 32, 64, 128, 
and 256 octets/packet. Packet size for the GRO 
project is 256 octets/packet. 

16.2.8 UPPER ATMOSPHERE RESEARCH SATELLITE 

16.2.8.1 UARS Mission Description . The Upper 
Atmosphere Research Satellite (UARS) project is 
directed toward the study of the middle and upper 
atmosphere through the use of an Earth-orbiting 
observatory that operates at an altitude of 600 km 
and an inclination of 57 degrees. The observatory 
was launched in the fall of 1991 from KSC, using 
the STS. Operational life of the satellite will be 18 
months, with the coverage of two Northern Hemi- 
sphere winters a major objective. The configura- 
tion of the UARS mission, including the supporting 
space and ground system elements, is illustrated in 
Figure 16-12. The following items a through c de- 
scribe the primary system support elements. 


b. GSFC Central Data Handling Facility . Instru- 
ment data processing is accomplished in the CDHF 
at GSFC. Data analysis and theoretical studies are 
conducted by members of the UARS science team 
through the use of remote analysis computers lo- 
cated at the Pi's facilities. 

c. TDRSS Support . Communications between 
the observatory and ground facilities are provided 
by the TDRSS SSA system. The UARS is also com- 
patible with the GN and the DSN. A 10-minute 
contact every orbit is baselined for tape recorder 
playbacks at 512 kb/s and real-time data transmis- 
sion at 32 kb/s. These contacts are normally suffi- 
cient for ranging, command, OBC memory dump- 
ing, and monitoring the performance of the obser- 
vatory. The forward SSA system is normally used 
for commanding at 1 kb/s. When SSA service is not 
available, command, real-time telemetry, and OBC 
dumping will be through the MA system. In addi- 
tion, an SSA emergency mode and a ground sta- 
tion mode will be available. 

16.2.8.2 Nascom Support for UARS Mission . As 
illustrated in Figure 16-12, the primary support 
provided by Nascom for the UARS mission is the 
extension of the UARS-TDRSS transmission chan- 
nels to GSFC UARS facilities via the BDS. 


a. GSFC Institutional Support . Flight opera- 
tions are performed with the use of GSFC institu- 
tional mission support systems. These facilities 
provide for satellite command and control, defini- 
tive orbit and attitude computation, command 
management, and data capture (MSOCC, FDF, and 
DCF). 



(«of S*pt«**b*f '*92) 

Figure 1 6- 12. UARS Ground System Data Flow Interfaces 


16.2.8.3 Remote Experimenter Network . Nine- 
teen Remote Analysis Computer (RAC) locations 
are being served by the GSFC CDHF for data pro- 
cessing and analysis activities. The following table 
lists the location and type of service to be provided 
to these RAC's. Secondary data distribution is via 
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the Project Support Communications Network 
(PSCN). 


CONTINENTAL LOCATIONS 


Ann Arbor, Ml 

*9.6 kb/s 

Atlanta, GA 

9.6 kb/s 

Boulder, CO (NCAR) 

*9.6 kb/s 

Boulder, CO (U of CO) 

9.6 kb/s 

Greenbelt, MD #1 

56.0 kb/s 

Greenbelt, MD #2 

56.0 kb/s 

Hampton, VA 

*9.6 kb/s 

Livermore, CA 

9.6 kb/s 

Palo Alto, CA 

*9.6 kb/s 


2 experimenters 
to share one line 

Pasadena, CA 

*9.6 kb/s 

San Antonio, TX 

*9.6 kb/s 

Seattle, WA 

9.6 kb/s 

Suitland, MD 

9.6 kb/s 

Toronto, Canada 

*9.6 kb/s 

Washington, DC 

*9.6 kb/s 

OVERSEAS LOCATIONS 

Bracknell, England 

*9.6 kb/s 


2 experimenters 
to share one line 

Paris, France 

9.6 kb/s 


* Requires connection with the GSFC CMS 

16.2.9 SPACE STATION ( ALPH A)PROG RAM 

NASA Deputy Administrator Decision Memoran- 
dum #25 transferred responsibility for "all for- 
ward and return link services that were to have 
been provided by CDOS, including Nascom II" [the 
Customer Data Operations System (CDOS) and 
Nascom II projects were canceled subsequent to 
the issuance of NASA Deputy Administrator Deci- 
sion Memorandum #25] to the respective flight 
program office(s). Nascom has not received re- 
quirements for Space Station (Alpha) support. Un- 
til such requirements are received and responded 
to, this section cannot be further developed with 
respect to Nascom's role in support of ground data 
transport. However, using the Mission Require- 
ments and Data Systems Support Forecast (501- 
803), December 1993/January 1994, as a guide, the 
following general comments and observations can 
be made: 

16.2.9.1 Early Phase Requirements . This informa- 
tion is presented to illuminate some aspects of the 
current Space Station (Alpha) from which Nascom 
support requirements may be expected: 

a. Space Station (Alpha) Space-Ground Data 
Rates. The intended Space Station (Alpha) C&T 


data rates planned to be transmitted on the SN 
(TDRSS) Space-ground link user services are: 

(1) S-band(SSA): 192 kb/s, return link, nor- 
mal; or 12 kb/s, return link, contingency. 

(2) S-band (SSA): 72 kb/s, return link, nor- 
mal; or 6 kb/s, return link, contingency. 

(3) Ku-band (KSA): 50 Mb/s, return link 

only. 

16.2.9.2 Space Station (Alpha) Preliminary Assem- 
bly Sequence . The new concept for the Space Sta- 
tion includes three distinct phases. Phase One ex- 
pands upon previously planned joint participation 
by U.S. and Russian crews in Mir and Shuttle oper- 
ations. Phase Two combines previously planned 
Station and Russian hardware to create an ad- 
vanced orbital research facility with a human tend- 
ed capability. Phase Three completes construction 
of this research facility to support a permanent hu- 
man presence. Table 16-2a depicts a preliminary 
assembly sequence and schedule for Phases Two 
and Three of the Space Station (Alpha). 

16.2.9.3 DELETED 
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16.2.9.4 DELETED 


Figure 16-13. DELETED 


NASCOM PLANNING 16-21 



Figure 16-14. DELETED 

16.2.10 EARTH OBSERVING SYSTEM (EOS) 

16.2.10.1 EOS Mission Description . The EOS is a 
multi-flight mission with the objective of acquiring 
geophysical, chemical, and biological information 
necessary for intense study of planet Earth. The 
EOS information system will build up over 10 years 
and then function at least 15 more years to accu- 
rately model processes that control the environ- 
ment. The program involves operation of numer- 
ous instruments on multiple spacecraft in both po- 
lar and non-polar orbit to support a large interna- 
tional user/scientific community. The U.S. is devel- 
oping multiple series of spacecraft, beginning with 
the EOS-AM series in 1998. Other EOS series in- 
clude EOS-PM, EOS-Chemistry, EOS-Aerosols, and 
EOS-Altimetry. Each spacecraft has a projected 
operational lifetime of 5 years, except for EOS- 
Aerosols which have an operational life of 3 years, 
with respective replacement spacecraft to provide 
observations of the Earth for not less than 15 
years. Both ESA and NASDA are planning Earth 
observing missions which complement the NASA 
flights; both will also have instruments on selected 
EOS flights. The CSA is providing one of the in- 
struments on EOS-AM1 and is sponsoring two in- 
terdisciplinary investigators. EOS will also encom- 
pass data from designated Earth Science Missions 
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Figure 16-15. DELETED 


Figure 16-16. DELETED 
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Table 16-2a. Space Station (Alpha) Preliminary Assembly Sequence and Schedule 


Assembly 

Flight 

Launch 

Designator 

Developer 

Element 

Launch 

Date 


1 

1 R 

Russia/U.S. 

FGB Energy Block 

05/97 

P 

2 

2R 

Russia/U.S. 

Airlock/STS Docking Adapter 

06/97 

H 

3 

1 A 

U.S. 

Node 1 

07/97 

A 

q 

4 

3R 

Russia 

Service Module 

07/97 

o 

E 

5 

4R 

U.S. 

Docking Node 

08/97 


6 

2k 

Russia/U.S. 

Truss 1, Gyrodynes 

09/97 

T 

W 

7 

5R 

Russia/U.S. 

Truss 2, PV Array 

10/97 

0 

8 

3A 

U.S. 

US Lab (3 System + 2 ISPR) 

10/97 


9 

4A 

U.S. 

Lab Outfitting, MBS 

11/97 


10 

5A 

U.S. 

SO Truss, MBSU, MT, TUS 

12/97 


11 

6R 

Russia 

Soyuz ACRV 

01/98 


12 

6A 

U.S./Canada 

PI Truss, TCS, SSRMS, S- 

04/98 


13 

7k 

U.S. 

Node 2, Cupola, S5, SPDM 

07/98 


14 

8A 

U.S. 

SI Truss. TCS, S-band, UHF 

10/98 


15 

9A 

U.S. 

P3/P4 Truss, PV Array 

01/99 

P 

16 

10A 

U.S. 

S3/S4 Truss, PV Array 

04/99 

H 

17 

7R 

Russia 

Service Module LSS 

06/99 

A 

c 

18 

1 1 A 

U.S. 

S6 Truss, PV Array 

07/99 

O 

E 

19 

1J 

Japan 

JEM 

10/99 


20 

2J 

Japan 

Outfitting Flight 

01/00 

T 

H 

21 

IE 

Europe 

APM 

04/00 

R 

22 

2E 

Europe 

Outfitting Flight 

07/00 

E 

E 

23 

3J 

Japan 

JEM EF 

10/00 


24 

12A 

U.S. 

US Hab 

01/01 


25 

8R 

Russia 

Research Module 1 

02/01 


26 

13A 

U.S. 

Hab Outfitting 

04/01 


27 

9R ; 

Russia 

Soyuz ACRV 2 

05/01 


28 

14A 

U.S. 

Outfitting Flight 

07/01 


29 

10R 

Russia 

Research Module 2 

08/01 


30 

1 1 R 

Russia 

Research Module 3 

09/01 

_ 


12R 

Russia/U.S. 

Solar Dynamic Element 

10/01 
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under the broad umbrella of "Mission to Planet 
Earth". 

16.2.10.2 Flight Profile . EOS spacecraft are self 
contained free-flyers, operating in sun- 
synchronous polar orbits. EOS-AM and -PM series 
will be launched from Vandenberg AFB, CA by the 
ATLAS II launch vehicle into 705 km near circular 
orbits with 100 minute periods. The launch vehi- 
cles for the EOS-Aerosol, -Chemistry and -Altimetry 
series are still TBD. The mission flight schedule for 
EOS is depicted in Table 1 6-3. 

16.2.10.3 SN/DSN/GN Support . The EOS mission 
requires support equivalent to one TDRS/TDRSII 
KSA channel. During normal operations, each EOS 
flight will utilize a TDRS KSA channel for approxi- 
mately 20 minutes per orbit for return link trans- 
mission of recorded science and engineering data. 
In addition, the capability exists for the spacecraft 
to transmit both real-time and recorded science 
and engineering data (selected data sets) via KSA. 
Real-time engineering and housekeeping data, 
and optionally dump data, will be transmitted via 
the corresponding SSA channel. Forward link com- 
mand requirements include real-time commands 
and spacecraft loads for handling by the space- 
craft onboard computer. Normal operations will 
consist of scheduled daily command loads. A num- 
ber of contingency modes involving KSA, SSA and 
SMA services will exist. Tracking services will be re- 
quired during orbit acquisition and for verification 
of the TDRSS Onboard Navigation System (TONS). 
Specific forward and return link services are de- 
picted in Tables 16-4 and 16-5. 

16.2.10.4 Earth Science and Data Information Sys- 
tem (ESDIS) Project Elements . The EOC at GSFC is 
responsible for mission control, mission planning 
and scheduling, instrument command support, 
and mission operations. All communications with 
the platforms and instruments go through the 
EOC. The EOC will interface with Instrument Con- 


trol Centers (ICC) and their Instrument Support 
Terminals (1ST). The ICCs are responsible for health 
and safety monitoring of the instrument and ob- 
servatory, planning and scheduling instrument op- 
erations, generating, validating, forwarding or 
storing command sequences, and providing instru- 
ment controllers with status for their instruments. 
ESDIS elements also include Distributed Active Ar- 
chive Centers (DAAC). 

16.3 GROUND NETWORK SUPPORTED MISSIONS 

This paragraph provides a description of selected 
missions or mission categories involving principally 
ground network tracking and data acquisition 
support and related unique Nascom ground com- 
munications support planning. 

16.3.1 INTERNATIONAL SOLAR TERRESTRIAL 
PHYSICS PROGRAM (ISTP) 

16.3.1.1 ISTP Mission Description . ISTP is a joint 
cooperative effort undertaken to study the solar- 
terrestrial physics of the near-earth space environ- 
ment or the Geosphere. This effort involves the 
spacecraft of three international agencies: The Na- 
tional Aeronautic and Space Administration 
(NASA), The Japanese Institute of Space and Astro- 
nautical Science (ISAS), and The European Space 
Agency (ESA). It also includes one Russian experi- 
ment, KONUS, on the US spacecraft “WIND". The 
US program is further subdivided into two pro- 
grams, 1) The Global Geospace Science project 
which is the NASA portion with two spacecraft, 
WIND and POLAR; and 2) The Collaborative Solar- 
Terrestrial Research Initiative (COSTR) that pro- 
vides for the development and operation of US ex- 
periments on the ISAS spacecraft, GEOTAIL and 
the ESA spacecraft, SOHO and CLUSTER. CLUSTER 
is a group of four satellites that orbit together in a 
predetermined pattern within the geosphere. The 
spacecraft will be launched over a period of three 
and a half years and during the latter part of the 


Table 16-3 

Schedule of EOS Missions 


MISSION 

LAUNCH 

MISSION 

LAUNCH 

MISSION 

LAUNCH 

MISSION 

LAUNCH 

MISSION 

LAUNCH 

EOS-AM 1 


EOS-PM1 

DEC 2000 

EOS-AEROI 

JUN 2000 

EOS-CHEM1 

DEC 2002 

EOS-ALT1 

JUN 2002 

EOS-AM2 

JUN 2003 

EOS-PM2 

DEC 2005 

EOS-AER02 

JUN 2003 

EOS-CHEM2 

DEC 2007 

EOS-ALT2 

JUN 2007 

EOS-AM 3 

JUN 2008 

EOS-PM3 

DEC 2010 

EOS-AER03 

JUN 201 6 

EOS-CHEM3 

DEC 2012 

EOS-ALT3 

JUN 2012 


EOS-AER04 

JUN 2009 


EOS-AER05 

JUN 2012 
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POCC payload operations voice coordination may 
accommodate up to nine voice loops provided by 
Nascom for this function between GSFC and JSC. 
Data services between JSC and GSFC that can be 
accommodated on the current in-place MDM sys- 
tem are regarded as STS standard service. 
JSC/MCC Remote POCC Capabilities Document, 
latest revision, provides detailed information on 
its remote POCC payload services. 

16.3.4.5 User-Nascom Interface . Remote POCC 
mission planners desiring access to the JSC/MCC 
payload services must plan and arrange interfaces 
with the Nascom System at GSFC. POCC's at GSFC 
are interfaced directly via the MSS for access to JSC 
remote POCC services. POCC's remotely located 
from GSFC must receive their payload data in 
4800-bit blocked form, if so originated in JSC. If 
originated as serial data, Nascom will deliver se- 
rial data to the GSFC interface to the user. Nascom 
will extend serial data via asynchronous modem 
services if rates are 1800 b/s or lower, or via syn- 
chronous data services equipped with Nascom- 
provided payload data deblockers for higher data 
rates. Such unique service to remote POCC's from 
GSFC may be provided on a reimbursable basis. 


16.4 DSN-SUPPORTED MISSIONS 

16.4.1 GENERAL INFORMATION 

Missions currently supported by DSN are listed and 
summarized in the "Deep Space Network Mission 
Support Requirements Document, JPL 870-14, Rev 
AH, April 1992," a quarterly publication similar to 
the 501-803. 

16.4.2 CURRENT ONGOING DSN MISSION SUP- 
PORT 

Section 15, Tables 15-2, 15-3, and 15-4 briefly de- 
scribe each DSN current mission, including data 
rates. 

16.4.3 FUTURE DSN MISSION SUPPORT 

Appendix C contains a brief description and ap- 
proximate launch date of each project included in 
the future DSN mission set. 
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SECTION 17 

NETWORK UPGRADE AND ADVANCED SYSTEMS DEVELOPMENTS AND PLANS 


17.1 PURPOSE 

This section reports current activities of Nascom 
and its supporting contractors in the area of 
Network Upgrade (NU) and Network Advanced 
Systems development. More specifically, this 
section encompasses the Nascom upgrades and 
projects scheduled or being planned for 
implementation over the next five years in support 
of Nascom's strategic planning activity. 

17.2 LONG RANGE PLANNING 
17.2.1 HISTORY 

a. Nascom 1986 Long-term Plan . Contained 
in a two-volume briefing book, the Nascom Long- 
term Plan (LTP) was developed in 1986 as an inter- 
nal document. Development of the LTP did two vi- 
tal things: (1) it made visible and thus provided 
recognition for some very significant change dri- 
vers to the Nascom System and (2) it demonstrated 
the need for a methodology for long-range plan- 
ning, including establishing a system baseline, 
high-level goals and objectives, plan strategies, 
elements of the plan itself, and a mechanism for its 
update. See paragraph 17.2.3 for a discussion of 
the Nascom Long Range Plan (LRP). 

b. Drivers for Change . Drivers for change are 
both internal and external, and they include 
environmental factors. Examples of principal 
external drivers include future network user 
requirements and new interfaces associated 
therewith [EOS/EOS Data and Operations System 
(EDOS) program] and the requirement for data 
rates and volumes an order of magnitude higher 
than those supported during the 1980s decade; 
the fact that technology advancements drive 
paradigm shift changes in the telecommunications 
industry; the SN has planned significant changes 
resulting from the advent of the STGT, the WSC, a 
larger TDRS constellation and the follow-on 
TDRSS-II; planned changes in user operations (e.g., 
telescience); requirements for interoperability 
with the space networks of other countries' space 
agencies (ESA and NASDA); budgetary pressures; 
and resource limitations. Internal drivers 
characterized as being principally of a 
management nature, e.g. becoming more 
proactive in the planning and implementation of 
telecommunications services in the decade of the 
90s and further, thereby asserting its leadership 
and fostering high-visibility participation in 
interagency planning and coordination activities. 
There are also the technology-based drivers that 


require internal Nascom R&D and study and 
analysis activities. In support of the foregoing, 
there are the planning and management actions 
necessary not only to maintain but also to expand 
the range and depth of skills available to Nascom 
both from its Civil Service staff and from its 
supporting contractor sources. Of particular 
impact are the Open Systems Interconnection (OSI) 
networking standards and protocols and the 
Federal policy mandating use of a selected set of 
these protocols in future Government networking 
systems (Government OSI Protocol Suite or GOSIP). 

c. Nascom Planning Council . The LTP also 
established a Nascom Planning Council chaired by 
the Division Chief and composed of Nascom 
Division management at the branch level and 
above, and including a research and planning 
manager. The primary focus is to provide 
coordinated planning direction to Division 
elements. The Planning Council conducts periodic 
planning activities and provides planning 
strategies, sets objectives, and allocates and 
assigns responsibilities and tasks. 

17.2.2 LTP/LRP GOALS AND OBJECTIVES 

At the highest level, Nascom goals and objectives 
may be summarized as follows: 

a. Provide efficient and effective institutional 
Nascom operational communications services that 
meet the requirements of the 1990s and beyond. 

b. Develop and maintain in-house 
management skills sufficient to meet these 
requirements for Nascom communications 
services. 

c. Develop the management, engineering, 
and operations plans necessary for effecting the 
necessary enhancements within the Nascom 
network and the development of "new" networks 
as required to meet the need of major flight 
programs, e.g., EOS. 

17.2.3 LRP SCOPE AND CONTENT 

A Nascom Long Range Plan (540-007, issued in 
January 1991) was developed in 1990 as a separate 
top-down mandated document prepared in 
accordance with guidelines and requirements 
promulgated by the GSFC Mission Operations and 
Data Systems Directorate (MO&DSD). The LRP was 
prepared in a form similar to that of the MO&DSD 
LRP; its content was coordinated with the that of 
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the MO&DSD LRP in a manner showing how 
Nascom plans and projects supported those of the 
Directorate. 

The Nascom 1990 LRP in effect captured in high 
level summary form the material contained in the 
NSDP of that year. One of the value added func- 
tions provided by the LRP was the establishment of 
a set of key service objectives and the description 
of how these objectives relate to the MO&DSD 
Directorate's service objectives as identified in the 
Directorate's LRP. The 1990 LRP further summa- 
rized near-term and long-term Nascom capabili- 
ties, and provided a look at Nascom's strategic 
plan for transition to the networks of the future. 

17.2.4 NEW DIRECTIONS 

At its inception, Nascom quickly discovered that it 
was not only operating at the forefront of tech- 
nology but was significantly instrumental in push- 
ing forward the technological developments nec- 
essary to fulfill its commitments to the space pro- 
gram. As a result, Nascom fielded a significant 
percentage of its infrastructure in the form of de- 
velopment items: proprietary and/or built for 
Nascom. The 4800-bit block was developed before 
there were international standards for data trans- 
mission in packetized form. Today, there are ma- 
ture (and maturing) international and govern- 
ment standards for data communication (ISO, 
CCITT, CCSDS, GOSIP, TCP/IP, etc.), and vendors are 
offering standards based equipment and software 
on a commercial, off-the-shelf (COTS) basis. Space 
and earth science programs are now employing 
these standards based COTS offerings. 

With the emphasis on doing NASA's business in 
ways which are "better, cheaper, faster," there is 
an opportunity now to develop a program for de- 
livery of even more efficient and effective tele- 
communication network services with emphasis on 
customer satisfaction, quality, technical excel- 
lence, and cost effectiveness. There is now an op- 
portunity to provide networking solutions adapt- 
able to all projects rather than developing sepa- 
rate and distinct solutions for each project. Stan- 
dards based COTS technologies, common to both 
the data user and data transport functions, allow 
this to happen. At the same time, there are op- 
portunities to attain economies of scale and 
shared resources by carefully bringing the commu- 
nication networks resources under single manage- 
ment. 

With these strategic visions in mind, Nascom is an 
active participant in the MO&DSD's RENAISSANCE 
(Reusable Network Architecture for Interoperable 
Space Science Analysis, Navigation, and Control 


Environment) initiative. Nascom is also a leading 
player in the development of the NASA Office of 
Space Communications Strategic Plan. Internally, 
Nascom has developed an Evolution Action Plan 
(NEAP) with the following objectives in mind: 

a. Review development plans for current and 
future systems to discover opportunities for inser- 
tion of standards based COTS products which offer 
opportunities to simplify operations, mainten- 
ance, and sustaining engineering support and thus 
reduce life-cycle costs. 

b. Review the necessity for Nascom-specific 
protocols and identify (industry) standards based 
protocols that can be used to guide COTS inser- 
tion. 

c. Review the Nascom-wide system engineer- 
ing practices to take advantage of the flexibility of 
COTS packages to reduce the number of systems 
and their operational complexity. 

d. Combine the results of these reviews into 
an Action Plan to chart the future of Nascom. 

17.3 CURRENT LRP STRATEGIC PLAN 

Present Nascom long-range planning strategy has 
separated advanced systems development activi- 
ties, which include a major EOS Communications 
(Ecom) project from specific and current NU activi- 
ties. Ecom draws upon work done for Nascom II 
before termination of Nil procurement authority 
in FY92-1. These two activity areas are conducted 
concurrently. The following is a definition and ex- 
panded explanation of these terms and strategies. 

17.3.1 DEFINITION OF NETWORK UPGRADING 

17.3.1.1 High-level Definition . NU consists of 
any additions, modifications or enhancements, or 
replacements needed for existing Nascom systems, 
in order to continue to reliably support NASA mis- 
sions using current aerospace data standards and 
practices. 

17.3.1.2 Scope of NU Activities . NU activities sus- 
tain the major Nascom ground network systems 
currently supporting the STS/Orbiter/Spacelab/ At- 
tached Payloads, Missions and Programs, and the 
life expectancy of the present on-orbit near-Earth 
and deep space missions that are supported by the 
GN, SN, and DSN networks. Additionally, NU up- 
grades these systems to provide support to the 
missions already planned for these existing ground 
network systems; e.g., HST, GRO, UARS (near- 
Earth missions), ISTP (high-Earth orbital missions), 
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and Magellan, Galileo, Ulysses, and MARS Global 
Surveyor (MGS) (deep space missions). 

17.3.1.3 NU for 4800-bit Block-based Systems . 
The requirement for continued use and sustaining 
engineering support of the present 4800-bit block 
format-based ground transport and switching 
system is included in the NU. Mission 
requirements for the SN/BDS system are expected 
to expire within 10 years as a result of expiration 
of existing and planned missions. 

17.3.1.4 NU Relationship to LRP . The Nascom 
LRP recognizes the continued need for planning 
modifications, upgrades, and subsystem replace- 
ments because of aging or obsolescence. Technol- 
ogy advancements and the continued ability to 
provide near-term planning for, and relatively 
quick-response to, new or changing requirements 
for these missions are important elements of the 
Nascom LRP-NU commitment. 

17.3.2 DEFINITION OF ADVANCED NETWORK 
SYSTEMS DEVELOPMENT ACTIVITIES 

17.3.2.1 High-level Definition . These activities 
encompass the entire spectrum required, directly 
or indirectly, to meet the requirements of flight 
projects employing advanced orbital systems com- 
munication methods. Entirely new Nascom sys- 
tems are under consideration with the focus being 
on CCSDS packet data transmission. These new 
systems will be data driven rather than schedule 
driven. An example is Ecom which is now being 
designed by Nascom for the exclusive support of 
EOS. As other flight projects formally establish 
their requirements, it would not be unreasonable 
to assume that additional Nascom projects could 
be initiated to provide a similar type of sys- 
tem/service for them. In this respect, the Ecom 
project serves as both a benchmark and a point of 
departure for evolving to the Nascom of the first 
decade of the twenty-first century. 

17.3.2.2 Scope of Activities . These activities in- 
clude: Nascom Advanced System Program technol- 
ogy studies and assessments particularly in the ar- 
ea of OSI Networking; participation in the ESDIS 
project initiatives at GSFC including certain R&D 
prototype developments in cooperation with GSFC 
Code 520 and the EOS project; continuing inves- 
tigation and information gathering of missions 
and users support requirements; inter-agency sys- 
tems planning and integration/coordination; de- 
velopment of architectural concepts, operations 
concepts, trade/feasibility studies and docu- 
mented system design requirements leading to 
and including the various phases of procurement 
and implementation of Ecom; the development of 
interface agreements, control documentation, ele- 


ment and user interface compatibility, acceptance 
testing and full system documentation. 

17.4 NETWORK UPGRADING ACTIVITIES AND 
PROJECTS 

In the following paragraphs, NU activity/project 
descriptions are each identified as: recently com- 
pleted, approved and undergoing implemen- 
tation, or proposed and under evaluation. 
Projects or activities reported as completed will be 
removed from Section 17 in subsequent updates. 
Results will be integrated into system descriptions 
in Sections 3 through 15, if system modifications 
have been completed; results may be reflected in 
follow-on projects or plans, if applicable. 

17.4.1 LOW SPEED NETWORK 

As noted in the introduction of the Low Speed 
Network (LSN) System Requirements Document 
(541-200), budgetary constraints have led Nascom 
to the decision to discontinue operation of the ex- 
isting MSS Low Speed System, commonly known as 
the teletype (TTY) network, as of October 1, 1994. 
But recognizing that requirements still remain for 
transport of tracking data and administrative mes- 
sage traffic, Nascom is implementing, separately 
from the MSS, a Low Speed Network. 

The LSN is being designed as two separate systems. 
For the administrative message traffic, Nascom 
plans to implement a standards based, COTS Ad- 
ministrative Message System (AMS) using a TBD 
electronic mail system as its core (see Figure 17-1). 
Using this system, users will be able to send their 
messages directly to the recipients' mailboxes. The 
Nascom operated message center will no longer 
be required and can be closed. Users will be re- 
sponsible for coordination of their communication 
with other system users, e.g., telephonically con- 
tacting the recipients of urgent messages to let 
them know an URGENT message has been placed 
in their mail box. As system administrator, Nascom 
will operate what might be called a "Help Desk 
for the electronic mail system. For users, this 
means that electronic mail standards and proto- 
cols will be utilized. No longer available will be 
the 5-level Baudot coded TTY messages, the 
NASCOP message standards will no longer apply, 
and message retransmission will be a function of 
the end users. 

For tracking data (non-human readable informa- 
tion), a LSN Tracking Data System (TDS) will be put 
in place with the switching/network management 
function at GSFC (see Figures 17-2 and 17-3). The 
TDS will support both ASCII and 4800-bit block. 
Baudot (5-level) code will not be supported. The 
TDS will provide interfaces for transport tracking 
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Figure 17- 1. Proposed LAN Administrative Message System 
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Figure 17-2. Proposed LSN Tracking Data System 
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Figure 17-3. Detail of Tracking Data System 


data: C-band, S-band and Improved Interrange, 
Vectors (IIRV). The functionalities that currently 
send and receive tracking data should not have to 
change, except to accommodate the discontinu- 
ance of Baudot code. Again the objective is to 
maximize use of COTS products, while recognizing 
that some software development will be required. 

Figure 17-4 is a high level portrayal of Nascom 
message switching as planned for October 1994. 

The schedule for the Low Speed Network (reflects 
acquisition occurring March and August 1994 and 
transition from the old system to the new occur- 
ring between August and October. 

17.4.2 DIGITAL MATRIX SWITCH SYSTEM RE- 
PLACEMENT (DMSSR) PROJECT 

17.4.2.1 Project Objectives . A Digital Matrix 
Switch Replacement Project has been established 
to meet the expanding needs of Nascom users for 
circuit switched services. The capacity of the cur- 
rent DMS, 192 input and 192 output channels, has 
been exceeded as more GSFC users have been add- 
ed to the Nascom network. The existing matrix 
switch cannot be economically expanded. 


The primary objective of the DMSR project is to de- 
velop a replacement system to meet the current 
and future circuit switching requirements of the 
GSFC user community. The chosen approach is a 
single switch with capability to interconnect at 
least 512 input ports and 512 output ports. Each 
port shall be simplex and consist of two signals 
(data and clock) at any rate from 100 bps to at 
least 2.048 Mbps, which shall be switched simulta- 
neously. The second objective is to provide for a 
diagnostics capability that will perform the fault 
isolation function down to the single board level. 

17.4.2.2 Background . In order to support the 
revised termination requirements for the MDM re- 
placement system, and the growing pool of GSFC 
users, a replacement DMS is urgently required. 
The existing DMS, a one-of-a-kind product devel- 
oped for Nascom by the Applied Physics Labora- 
tory, implements Clos non-blocking switch theory 
and consists of input buffers, a matrix switch, out- 
put buffers and a DMS Control System. Figure 5-2 
in Section 5 presents a simplified block diagram of 
the current DMS, and paragraph 5.3 provides a de- 
scription of the existing system. Figure 1 7-5 repre- 
sents one possible architecture of the replacement 
system. The DMSR will be procured using a modu- 
lar implementation approach and commercial off- 
the-shelf (COTS) hardware and software to the 
maximum extent possible. 
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Figure 17-4. Nascom Message Switching as Planned for October 1994 
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17.4.2.3 Project Management Plan (PMP) . A 
preliminary PMP document has been developed 
for the Level II DMSR project. As a Level II project, 
the document identifies the organizational rela- 
tionships and responsibilities for the management 
and technical support throughout all phases of the 
DMS life cycle. This plan covers management ap- 
proach, technical approach, system transition, op- 
erations, support and logistics. 

17.4.2.4 Management Approach . The manage- 
ment approach for the DMSR Project is based on 
the MO&DSD System Management Plan (SMP) 
which outlines the documents and reviews need- 
ed. This ensures that all requirements for the DMS 
are identified and trace throughout each phase of 
the DMSR Project. The DMSR Project organiza- 
tional interfaces include: the NASA Communica- 
tions Division; the Systems Engineering Branch; 
the Communications Engineering Section; the Sys- 
tems, Engineering, and Analysis Support (SEAS) 
contractor; the Computer Systems Section; the 
Operations Management Branch; the Communica- 
tions Management Section; the Network and Mis- 
sion Processing Equipment (ADPE) Procurement 
Branch; and the Logistics Supply Depot (LSD). 

a. NASA Communications Division . The 
NASA Communications Division (Code 540), in ful- 
filling its responsibility for ensuring that Nascom's 
present and future requirements are met, has the 
overall system responsibility for the DMS replace- 
ment project. 

b. System Engineering Branch . The Systems 
Engineering Branch (Code 541) has the overall re- 
sponsibility for the procurement of the DMS re- 
placement. The Communications Engineering Sec- 
tion, within the Systems Engineering Branch, is the 
project office for the DMS replacement project 
and has the responsibility for developing the re- 
quirements, procuring the DMSR, and implement- 
ing the DMSR into the Nascom network. 

c. Communications Engineering Section . The 
Communications Engineering Section (Code 541.1) 
has assigned a DMSR Project Manager (PM). The 
PM is responsible for the day-to-day activities of 
the DMSR Project which will culminate in the suc- 
cessful procurement of a DMSR. In addition, the 
DMSR PM has the overall responsibility of ensuring 
the DMSR is tested by both the engineering and 
operations teams before it is accepted from the 
DMSR vendor by NASA. The PM, as part of the 
Communications Engineering Section, is responsi- 
ble for the following activities: 

(1) Interface with and solicit support from 
the Computer Systems Section, the Operations 
Management Branch, the Communications Man- 


agement Section, the Quality Assurance office, the 
Logistics Supply Depot, the SEAS contractor, and 
the ADPE Procurement Branch. 

(2) Develop the requirements for the 
DMSR specifications. 

(3) Procure the DMS replacement system, 
to include: performing an industry survey of possi- 
ble switch vendors, writing a sources sought syn- 
opsis to solicit vendor's inputs, providing technical 
documents and technical inputs to the ADPE pro- 
curement personnel for inclusion into the Request 
for Proposal (RFP) package, assembling a Source 
Evaluation Board (SEB) and subsequent evaluation 
criteria, coordinating with the chosen DMSR ven- 
dor the schedule and content of required meet- 
ings and reviews, overseeing the progress of the 
DMSR vendor during switch fabrication, and en- 
suring DMSR requirements are tested at the fac- 
tory and on-site. 

d. SEAS Contractor . The SEAS contractor, as 
the engineering support contractor, supports both 
the Communications Engineering Section and the 
Computer Systems Section. 

(1) The SEAS contractor is responsible for 
the following activities, as requested by the Com- 
munications Engineering Section: 

(a) Provide documentation support to 
include review of system documents, as required. 

(b) Support acceptance testing efforts, 
as required, both at the factory and at GSFC. This 
may include testing of patch panels, to be pro- 
vided by the DMSR vendor. 

(c) Support the transition from the ex- 
isting DMS to the DMSR. This includes preparing 
the facilities (HVAC, power, etc.) for the installa- 
tion of the DMSR. 

(d) Provide sustaining engineering 
support for the DMSR. 

(2) The SEAS contractor is responsible 
for the following activities, as requested by the 
Computer Systems Section: 

(a) Development of the Interface Re- 
quirements Document (IRD) and the Interface 
Control Document (ICD) between the DMSR con- 
troller and the DCSU. 

(b) Negotiations with the DMSR ven- 
dor regarding the best approach for providing the 
DMSR controller / DCSU interface. 
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(c) Development of software needed 
for the DMSR controller / DCSU interface. 

(d) Maintenance of and upgrades to 
the DMSR controller / DCSU interface. Also, if the 
DMSR controller source code is obtained, the 
maintenance of the DMSR controller software will 
be necessary. 

e. Computer Systems Section . The Computer 
Systems Section (Code 541.2) will be responsible 
for the development of both the IRD and the ICD, 
which describe the interface formats needed be- 
tween the DMSR controller and the DCSU. Code 
541.2 will develop the IRD for inclusion in the RFP 
package. After vendor selection, Code 541.2 will 
negotiate the details of the external computer in- 
terfaces with the DMSR vendor, and subsequently 
develop and ICD. Code 541.2 will also ensure that 
software revisions received from the DMSR vendor 
for the DMSR controller and/or the external com- 
puter interfaces are satisfactory for the environ- 
ment the DMSR will be in. In general, Code 541.2 
is responsible for all matters relating to the soft- 
ware of the DMSR controller and its external com- 
puter interfaces. 

f. Operations Management Branch/ Commu- 
nications Management Section . The Operations 
Management Branch (Code 542) and in particular, 
the Communications Management Section (Code 
542.2), is responsible for coordinating the transi- 
tion from the existing DMS to the DMSR. Also, 
Code 542.2 is responsible for the operations por- 
tion of the overall engineering/operations testing. 
In addition. Code 542.2 will be overseeing the op- 
erations and maintenance (O&M) of the DMSR 
after is has been installed and tested. O&M sup- 
port will be supplemented by the Network and 
Mission Operations Support (NMOS) contractor. 
Code 542.2 will also answer questions and provide 
support to the PM when operations issues arise. 

g. NMOS Contractor . The NMOS contractor 
will be responsible for preparing the DMSR transi- 
tion plan under the direction of Code 542.2. They 
will also support the operational testing portion of 
the DMSR acceptance testing. 

h. Quality Assurance . The Quality Assurance 
office. Code 303, is responsible for all quality assur- 
ance issues associated with the DMSR Project. This 
will be done in accordance with the Nascom QA 
Plan and includes reviewing the System Design 
Specifications (SDS) and the Statement of Work 
(SOW) before they are part of the RFP package 
and, once a vendor is selected, ensuring the ven- 
dor is following proper QA procedures. Also, Code 


303 will obtain Defense Contract Management 
Support (DCMS) as appropriate. 

i. ADPE Procurement Branch . The ADPE Pro- 
curement Branch, Code 243, is responsible for the 
preparation of the RFP package an all contract ac- 
tivities. 

j. Logistics Supply Depot (LSD) . The LSD, 
Code 535, will be responsible for all logistics issues 
associated with the DMSR Project. This includes 
the overall spares provisioning and the repair pro- 
cess. In addition, the LSD and Code 535 will review 
DMSR documentation, develop a sparing analysis, 
track card-level maintenance failures once the 
DMSR is delivered, provide repair support when 
the DMSR vendor warranty has expired, and ad- 
minister sustaining logistics following operational 
acceptance (unless the option in the DMSR con- 
tract for DMSR vendor-provided sustaining logis- 
tics is exercised). 

17.4.2.5 Technical Approach 

a. General . The DMSR will use commercial 
off-the-shelf hardware and software to the maxi- 
mum extent feasible. Detailed system functions 
and performance are to be described in DMSR Sys- 
tem Requirements Document and DMSR Specifica- 
tion (documentation under development). 

b. Hardware and Interface Configuration . 
The DMSR will support the capability to compare 
the input and output of any configured channel, 
and to alert the operator in the event errors are 
detected. The DMSR will not provide storage of 
the throughput data. 

The DMSR will possess its own internal control sys- 
tem. External control of the DMSR is via the DCS 
Upgrade (DCS/U); the DMSR vendor must demon- 
strate that its system will successfully interface 
with the DCS/U for external control and manage- 
ment activity. 

The DMSR will be packaged in standard equip- 
ment racks. The capability to manually configure 
each channel is required and shall be implemented 
during the installation. 

c. System Implementation Strategy . The 

DMSR implementation strategy contains four 
stages: a procurement phase, an installation 

phase, a testing phase, and a transition phase. 

(1) Procurement . The training, system 
documentation, logistics support, and O&M proce- 
dures will be developed during the procurement 
phase. 
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(a) Training . Training includes the 
planning and conduct of the training program for 
the DMSR. This element includes developing and 
presenting the appropriate courses covering oper- 
ations, maintenance, engineering, and follow-on 
support. This work will initially be performed by 
the vendor. The vendor's training will educate 
staff from the Networks Technical Training Facility 
(NTTF), the SEAS contractor, and the NMOS con- 
tractor. Subsequent training will be performed by 
NTTF personnel. This includes classes and materi- 
als needed by the operations personnel through- 
out the life of the DMSR. As recommended by 
Code 535, the format of the training classes and 
materials will follow standard 535-TIPCPT-001 . 

(b) Documentation . The following 
categories of project and system related docu- 
mentation will be provided as part of the DMSR 
project: project management, system definition, 
system design, testing, training, logistics, main- 
tenance, and operations. The schematics, cata- 
logs, and manuals delivered with the DMSR will be 
provided by the vendor. Documents delivered 
with the DMSR and subsequent updates to the 
documentation will be brought under Configura- 
tion Management (CM) control. The CM of these 
documents throughout the life of the DMSR will 
be provided by the SEAS contractor. 

(c) Logistics . Code 535 will be respon- 
sible for logistic support of the DMSR. Code 541 
will establish the appropriate interfaces with Code 
535 to assist in planning logistics support and in 
ensuring that initial spares and follow-on spare 
parts provisioning are accounted for in the pro- 
curement process. 

(d) Facilities . No major revision will be 
required to the facilities that house and support 
the current system in order to accommodate the 
DMSR. Depending upon the software mainten- 
ance approach selected (in-house versus DMSR 
vendor), additional facilities may be required to 
support a DMSR development system. 

(e) DMSR Development Facility . The 
DMSR contractor will be required to provide a 
scaled down DMSR system for the development 
and testing (verification and validation) of DMSR 
hardware and software, including the DCS/U inter- 
face. 

(2) Installation . Installation includes the 
preparation of Building 3/14 Room E171 and the 
facilities needed to install the DMSR. Prior to de- 
livery, Room E171 must be prepared to accept the 
DMSR; the preparation involves floor location, 
HVAC, power, lighting, and cooling. Also, cabling 
and other ancillary equipment may need to be 


provided and installed as well as preliminary 
check-outs of the DMSR before testing begins. 
The SEAS contractor will be responsible for this ef- 
fort. 

(3) Testing . Two phases of testing are 
planned for the DMSR: at the factory, and on-site. 

(a) Factory Acceptance Testing . For 
factory acceptance testing, a vendor-provided Ac- 
ceptance Test Plan (ATP) and Acceptance Test Pro- 
cedures (ATPr) (to include a maintainability demo) 
will be followed. This will be provided to NASA for 
approval prior to the beginning of any acceptance 
testing. 

(b) On-site Testing . For the on-site 
testing of the DMSR before government accep- 
tance, a System Test Plan (STP) will be generated 
to describe the tests to be performed. The details 
of the test to be performed prior to acceptance are 
documented in the System Test Procedures (STPr). 
This activity will be a coordinated effort between 
Code 541 and Code 542, with oversight provided 
by the PM. 

(4) Transition . The transition phase in- 
volves the changeover from the current DMS to 
the new DMSR. These efforts will be documented 
in a Transition Plan, to be developed by Code 
542.2. Engineering support (engineering changes, 
material requisitions, etc.) will also be provided as 
needed. 

(a) Hardware Maintenance . Hard- 
ware maintenance includes the maintenance of 
the delivered DMSR throughout its lifetime. Dur- 
ing the first two years of its operational life, the 
DMSR maintenance is planned to be provided by 
the vendor via an extended warranty. After the 
first two years, maintenance will be provided by 
the NMOS contractor, with repair and spare parts 
support from the LSD and Code 535 (or the ven- 
dor, if the continued maintenance option on the 
contract is exercised). 

(b) Software Maintenance . Software 
maintenance includes the maintenance of all sys- 
tem software, including: 

1. Commercial Software in the 
DMSR Controller . Maintenance and upgrades for 
the DMSR controller software will be provided by 
the vendor; this software is proprietary (unless 
NASA received the source code, as asked for in the 
RFP package). Nonetheless, if the vendor goes out 
of business, NASA will receive the source code to 
provide maintenance. 
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2. Developed Software for the 
DMSR Controller/DCSU Interface . This software is 
planned to be developed, as much as possible, by 
SEAS via Code 541.2 direction. This includes the 
maintenance of the software. However, the de- 
tails of this interface are yet to be determined, 
pending vendor selection. 

(c) Operations Plan . The DMSR should 
perform the same generic circuit switching func- 
tions as the current DMS. Procedural revisions, as 
required, will be accomplished by Code 542. 

d. Security . The DMSR is an unclassified sys- 
tem and is part of the NASA Operational System 
(NOS). The sensitivity level of the data is 3. The 
computer system, will adhere to NASA guidelines 
for Automated Data Processing Equipment 
(ADPE). 

17.4.2.6 Status . The DMSR project is undergo- 
ing a thorough requirements review in conjunc- 
tion with a comprehensive survey of the market 
for COTS vendors whose system(s) might, with mi- 
nor modification, be adapted to meet Nascom re- 
quirements. 

17.4.2.7 Schedule . Some tentative major mile- 
stones for the DMS replacement project are: 


a. 

RFP Release 

03/94 

b. 

Contract Award 

07/94 

c. 

Installation Complete 

05/95 

d. 

Acceptance Testing Complete 
and Turn-over to Operations/ 

03/97 


ORR 



17.4.3 STGT-DIS RELATED ACTIVITIES 

17.4.3.1 STGT-DIS Overview . The establishment 
of the Second TDRSS Ground Terminal (STGT) is a 
major goal of the planned augmentation of SN in 
accordance with the approved NASA 10-year plan 
for SN. It is a level 1 project of the MO&DSD. The 
STGT is an additional element of the SN. The STGT 
will be established as an enhancement of the 
TDRSS ground segment, which is currently defined 
as the WSGT and the collocated NGT. Figure 17-6 
illustrates the relationship of the STGT to the 
TDRSS and to other elements of the SN. The func- 
tional features of STGT and its Data Interface Sys- 
tem (DIS) are summarized in the following para- 
graphs: 

a. The STGT is to provide, in conjunction with 
the TDRSS, forward (ground-to-space) and return 
(space-to-ground) communication and tracking 


services for TDRSS user satellites, as well as to per- 
form tracking, telemetry, and command functions 
fortheTDRS. 

b. The STGT is required initially to function in 
an operationally ready standby capacity in the 
event of failure or performance degradation of 
existing WSGT facilities. 

c. The STGT is being established in a facility 
provided by the Government at the NASA White 
Sands Test Facility (WSTF), NM, approximately 
3 miles north of WSGT/NGT. 

d. The STGT is also required to process and 
provide the required levels of protection for 
national security classified information. In 
addition to its other functions, the DIS will also 
provide support for classified information by 
receiving, processing, storing, transmitting and 
otherwise handling it in a secure manner. 

e. The DIS is presently being implemented, 
and includes MDM and SM equivalent subsystems 
for interface with the Nascom-provided Common 
Carrier Interface (CCI), at WSGT, via the 
Interfacility Link (IFL). The DIS includes matrix 
switching for routing of user service interfaces and 
a defined set of interfaces allocated to both the lo- 
cal GTE CCI and the IFL. MDM channels must be 
reterminated and reassigned for these interfaces 
which will be controlled through NCC, DIS, and 
ADPE software. 

f. The Interfacility Link (IFL) between 
WSGT/NGT and STGT provides for the exchange of 
user data between the NGT and the STGT-DIS. In 
addition it provides for the baseband data cross- 
strapping and interconnection for access to di- 
versely routed Nascom common carrier data 
throughput systems and the single 50 Mb/s service 
at WSGT. 

g. STGT follow-on plans call for refurbish- 
ment and replacement of the WSGT/NGT with a 
WSGT Upgrade (WSGT/U) after the STGT is oper- 
ational. The WSGT/U will be functionally identical 
to the STGT. While the WSGT will be down for re- 
furbishment, the STGT will assume the primary 
TDRS support role. When the WSGT/U returns to 
service, both ground stations will transition to a 
joint support role for the expanded TDRS constel- 
lation planned for the Space Station era. 

h. STGT/WSGT/U Phasing Schedules. The 
STGT is scheduled to come online starting 4/1/94 , 
and will operate in parallel with the WSGT/NGT 
for 6 months until 10/1/94, with a gradual shift of 
operational services to the STGT. Standalone STGT 
service starts in 10/31/94 when WSGT/NGT will go 
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Figure 17-6. The NASA Space Network Configuration with the STGT 


down for its refurbishment. Final configuration 
will be achieved when WSGT/U returns to service, 
12/15/95. 

17.4.3.2 Nascom Support . Nascom will provide the 
communications services between the WSGT/ 
STGT-DIS ground system baseband interfaces and 
corresponding SN user elements. New configura- 
tion requirements are being identified and 
Nascom/SEAS support studies are in progress as a 
continuing effort for both near-term (pre-Space 
Station) and Space Station era planning. Establish- 
ment of the initial STGT-DIS facility along with the 
other new SN-related requirements has a signifi- 
cant impact on the existing Nascom System archi- 
tecture (i.e., MDM, DMS, and MACS equipment, 
and CSS software). Nascom support for the 
STGT /WSGT/U consists of the following activities: 

a. Assume an active role in the development 
oftheDIS. 

b. Design and construction/implementation 
of the IFL fiber-optic cables and transmission sys- 
tems, including the cross-strapping designs for ac- 
cess to/from the CCIs. Figures 17-7a, b, and c pro- 
vide an IFL configuration overview for forward 


and return link baseband interface systems respec- 
tively. Note in Figure 1 7-7 (a) that each site s re- 
turn link includes a two-channel cross-strapping 
multiplexer which aggregates the MDM composite 
outputs of both sites. Thus, the return common 
carrier transport links become redundant, each 
carrying the same (both sites) data; one will be 
designated as prime link, the other will be an al- 
ternate (or backup) link as in the present BDS. Al- 
so note in Figure 17-7(b) that the forward link uses 
a similar prime and alternate arrangement; both 
links are bridged into WSC carrying the same for- 
ward data, but only one transport system is termi- 
nated at the destination at both sites through an 
A/B switch selection arrangement. Figure 17-7(c) 
shows that the 50 Mb/s service is available to only 
one return link at any given time. However, each 
site will have non-simultaneous, schedulable ac- 
cess to the SM. 

c. Implementation of the new CCI for 
STGT /WSGT/U, and the attendant upgrade of the 
redundant long-haul transport system architec- 
ture; one of the two existing BDS Earth Stations 
will be relocated to the STGT location in April 
1994. 


NETWORK DEVELOPMENTS/PLANS 17-11 





NETWORK DEVELOPMENTS/PLANS 17-12 


















































540-030 

FY94-2 



GEAM ES 


Figure 17-7(c). IFL and Associated Systems Overview 
Snowing High Rate Data/Video Return Link Interface 


d. Attendant upgrades of CSS/DMS systems, 
and NCC interface as required. 

e. Implementation of the local administrative 
telephone service. 

17.4.3.3 Status of Nascom Support . Items b and d 
of paragraph 17.4.3.2 are the major Nascom sup- 
port efforts underway at this time: 

a. IFL Implementation . The IFL implementa- 
tion is complete and fully operational. 

b. Nascom Interface Integration . Interface 
integration plans for the new DIS/Nascom MDM 
channel interface for NCC/CSS scheduling control, 
including port address assignments, has been the 
subject of close Code 530/540 coordination. Pres- 
ently, Nascom MDM channels are hardwired to 
TDRSS interface channels. This will change: the 
new STGT /WSGT / U complex will provide baseband 
switching functions between TDRSS user services 
and the ground transport interface via the Low 
Rate Black Switch (LRBS). Nascom has negotiated 
a series of port addresses for the MDM system 
which reassigns and dedicates MDM channels to 
generic TDRSS user service types and to specific us- 


er data streams to and from control center (MOCC) 
interfaces. These assignments are documented in 
the Nascom Space Network Systems Upgrade 
(MDMR/MACSU) Operations Transition Plan, 542- 
045, dated September 1992. This document is con- 
figuration controlled by the Nascom Division CCB. 
These ITU/OTU assignments will also be incorpo- 
rated in the Nascom SN Data Book, 542-016. 
FTS2000 may also play a role in the interface inte- 
gration plans by supporting a portion of the 
voice/data links into STGT. 

17.4.4 INTERBUILDING COMMUNICATION LINK 
UPGRADE (ICLU) 

17.4.4.1 Background . The ICLU is a Level 3 
project that will provide for the bandwidth and ac- 
cess requirements between the Nascom facility in 
Building 14 and the various other buildings on 
GSFC that house or will house Nascom service us- 
ers. A review of major projects such as Second 
TDRSS Ground Terminal, the Space Station Free- 
dom, EOS, and other projects indicates an ex- 
panded requirement for communications be- 
tween Nascom and GSFC POCC's and data process- 
ing centers. The ICLU will provide the link band- 
width and channels, using fiber optic cables, be- 
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tween each user facility and Nascom to meet these 
future needs and in the process will replace exist- 
ing systems designed for requirements and tech- 
nologies (copper cables) of the 70's (IBDTS) and 
80's (IBDDR). 

17.4.4.2 Description . Individual circuit fiberoptic 
cables have been or will be installed between 
Nascom and the various GSFC buildings that house 
facilities requiring this wideband service. The ICLU 
will utilize fibers provided by the Operational 
Mission-Oriented Nascom Interbuilding Fiber Op- 
tic Cable Plant (Figure 5-16). Interfacing the fiber 
optic cables are Fiber Optic Transceivers (FOT). 
Connections on the FOTs will be an RS-422 and 
BNC connectors. The ICLU design is a channel 
dedicated facility wherein every channel to and 
from entities is preassigned; a patchable, common 
redundant path feature is incorporated into the 
design to provide for a make good capability in 
the event of a hardware or fiber cable failure. In- 
dividual channel data rates of up to 10 Mb/s are to 
be supported, thus maintaining consistency with 
the replacement MDMs. 

17.4.4.3 Schedule . The implementation schedule 
contains the following major milestones: 


a. Prototype submittal 

05/94. 

b. FOT Contract Award 

07/94. 

c. Phased delivery of FOTs 

08/94-11/94. 

d. On-going integration and test 

08/94-11/94. 

e. Acceptance testing 

09/94-12/94. 

17.4.5 HIGH DATA RATE SYSTEM 

STATISTICAL 


MULTIPLEXER REPLACEMENT (SMR) 

17.4.5.1 Concept . The present 50 Mb/s statistical 
multiplexer hardware transporting the Spacelab 
high rate multiplexer aggregate signal between 
the White Sands Complex and the receiving sta- 
tions at GSFC, JPL, JSC, and MSFC is approaching 
the end of its economic life. A continuing require- 
ment for the data rates and services it supports ne- 
cessitates that the hardware be replaced maintain- 
ing current functionality in design but incorporat- 
ing new technology that will enhance its reliability 
and supportability throughout the decade of the 
90's and into the next century. A formal system re- 
quirements review has been conducted by 
Nascom, some of the main features of which are 
summarized in the following paragraphs. {Note: 
Though funds are not now available to implement 
this project, Nascom intends to have documenta- 
tion completed to the point where a Request for 


Proposal could be released on relatively short no- 
tice in the event that funds became available.} 

17.4.5.2 Requirements . The SRR for the SMR was 
conducted in November, 1993. It envisaged a sys- 
tem capable of transporting an 85 Mb/s aggregate 
at the carrier interface and providing at least four 
(modularly expandable to eight) user channel in- 
terfaces, each of which could accept user data 
rates from approximately 2 Mb/s up to 85 Mb/s, 
less SMR overhead. The system would be capable 
of being remotely controlled via a Simple Network 
Management Protocol (SNMP) interface. For local 
monitoring purposes, a local control and monitor- 
ing capability is intended. Additionally, at the 
WSC, the equipment would be required to main- 
tain the integrity of the current interfaces at the 
WSC as set forth in the HRDLM ICD, dated June 25, 
1992, and with paragraph 4.2.1. 9 of STGT docu- 
ment STGT-HE-06-01 . 

Differing from today's system, there would be one 
terminal per NASA site: WSC (broadcast), and 
GSFC, JSC, JPL, and MSFC (receiving). Redundancy, 
sufficient to allow for automated failover be- 
tween prime and redundant system elements to 
provide data path availability of at least 0.999975 
over any continuous 10,000 hour operating pe- 
riod. Additional receiving terminals, e.g., at the 
EROS Data Center in Sioux Falls, SD, could be add- 
ed modularly to the system if and as requirements 
warranted. The SMR would maintain the capabil- 
ity for dynamic clock tracking of user data, adjust- 
ing the output at the user interface. 

Another differentiating point between the cur- 
rent SM and the SMR is that the data rates sup- 
ported by the SMR will require fiber optic cables 
for on-site transmission of user data at the higher 
rates. 

17.4.6 WBDS INTERSWITCHING CENTER - 64K 
OVERSEAS MULTIPLEXER CIRCUITS 

An ongoing effort is underway to procure a 64- 
kb/s trunk line between GSFC and each of its for- 
eign space agency counterparts. The goal is to 
provide a vehicle to support existing and planned 
project requirements and to reduce costs incurred 
by leasing individual voice and 9.6-kb/s circuits. 
Seven overseas centers have been identified to re- 
ceive these services. 

17.4.6.1 European Space Operations Center 
(ESOC) at Darmstadt. Germany . One full-duplex 
64-kb/s data trunk is to be installed. The 64-kb/s 
service is to be multiplexed using a TimePlex 
Link/2 -f- multiple aggregate multiplexer. The 
trunk is to be configured for two 16-kb/s voice, 
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one 8-kb/s voice, one 9.6 sync, and one 1200-baud 
teletype (riding on a 9.6 sync) channels. 

17.4.6.2 European Space Operations Center 
(ESOC) at Vilspa, Spain . One full-duplex 64kb/s da- 
ta trunk is to be installed. The 64-kb/s service is to 
be multiplexed using a TimePlex Link/2 + multiple 
aggregate multiplexer. The trunk is to be config- 
ured for one 8-kb/s voice, one 9.6 sync, and one 
40.8-kb/ssync channels. 

17.4.6.3 German Space Operations Center (GSOC) 
at Ober Pfaffenhofen. Germany . Existing services 
are to be reconfigured to add a 64-kb/s aggregate 
capability. The 64-kb/s service is to be multiplexed 
using existing General DataComm equipment. 
The aggregate service is to be configured for two 
16-kb/s voice, three 9.6 sync, and one 300-baud 
async channels. 

17.4.6.4 Centre National D'Etudes Spatiales 
(CNES) at Toulouse. France . One full-duplex 64- 
kb/s data trunk is to be installed. The 64-kb/s ser- 
vice is to be multiplexed using a TimePlex Link/2 + 
multiple aggregate multiplexer. The trunk is to be 
configured for two 16-kb/s voice, one 8-kb/s voice, 
one 9.6 sync, and one 1200-baud teletype (riding 
on a 9.6 sync) channels. 

17.4.6.5 National Space Development Agency 
(NASDA) at Tokvo/lbariki. Japan . One fullduplex 
64-kb/s data trunk is to be installed. The 64-kb/s 
service is to be multiplexed using a TimePlex 
Link/2 -I- multiple aggregate multiplexer. One 32- 
kb/s voice, one 9.6-kb/s, and one 1200-baud async 
channels is the initial proposed configuration for 
the trunk. 

17.4.6.6 Institute of Space and Astronautical Sci- 
ence (ISAS) at Saoamihara, Japan . One full-duplex 
64-kb/s data trunk is to be installed. The 64-kb/s 
service is to be multiplexed using a TimePlex 
Link/2 + multiple aggregate multiplexer. One 32- 
kb/s voice, one 9.6-kb/s, and one 1200-baud async 
channels is the initial proposed configuration for 
the trunk. 

17.4.6.7 Ground Network (GN) Station at Ber- 
muda . One full-duplex 64-kb/s data trunk is to be 
installed. The 64-kb/s service is to be multiplexed 
using a TimePlex Link/2 + multiple aggregate mul- 
tiplexer. The trunk is to be configured to support 
current project requirements. 

17.4.6.8 Schedule . The schedule for overseas in- 
stallations is as follows: 

ESOC at Darmstadt, Germany February 1994 


ESOC at Vilspa, Spain 

March 1994 

GSOC at Ober Pfaffenhofen, 

Germany 

March 1994 

CNES at Toulouse, France 

April 1994 

NASDA at Tokyo, 


Ibariki, Japan 

Late Summer 1994 

ISAS at Sagamihara, Japan 

Late Summer 1994 

Bermuda GN 

Late Winter 1994 


17.4.7 FTS2000 IMPLEMENTATION PROJECT 

17.4.7.1 Background . Public Law 100-440 im- 
poses a requirement that all government agencies 
use GSA's FTS2000 contract to meet their network 
telecommunications requirements. In order for 
the FTS2000 to meet Nascom performance require- 
ments, significant contract modifications needed 
to be made. In early 1991, the GSA, in conjunction 
with Nascom and AT&T (NASA is assigned to Net- 
work A for FTS2000 services; the vendor for Net- 
work A is AT&T), undertook to define the contract 
modifications that would be needed if FTS2000 
were to provide the required services and meet 
Nascom's performance requirements. Three con- 
tract modifications were identified: Network Ser- 
vice Assurance Plan (NSAP), Special Routing (SR), 
and Alternate Network Connectivity (ANC). 

a. Network Service Assurance Plan . The NSAP 
contract modification was awarded in April 1993. 
Basically, the NSAP provides for flagging and tag- 
ging of FTS2000 Network A assets supporting 
Nascom, maintains Nascom's position within the 
National Security Emergency Preparedness pro- 
gram, provides for enhanced maintenance re- 
sponse and special coverage, implements auto- 
matic restoration and reconfiguration within 
Nascom's allocation of Network A resources, and 
provides for site visits by the vendor. 

b. Special Routing . The SR contract modifica- 
tion is anticipated to be awarded by December 
1993. It provides for the establishment of a totally 
diverse terrestrial route, on an end-to-end basis, 
between any two points supported by Nascom 
where such route diversity is a requirement. 

c. Alternate Network Connectivity . The ANC 
contract modification is anticipated to be awarded 
by September 1993. It makes provision for use of 
domestic satellite services between given loca- 
tions, e.g., by making use of GTE Americom earth 
stations currently contracted for by Nascom. 
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17.4.7.2 Network Site Types . The NSAP contract 
modification makes provision for five different site 
types, i.e., node configurations. A center's com- 
plement of NSAP provided equipment may be 
comprised of multiple site types. Each site type 
will be briefly described in the following para- 
graphs. 

a. Primary Site . The distinguishing feature of 
the primary site is the network management capa- 
bility. Nascom will perform the network manage- 
ment function, remotely from GSFC, of the 
FTS2000 resources allocated for Nascom support. 
Network management functions may be exten- 
sively automated; however, human interaction 
with the network via remote terminal or worksta- 
tion interfaces is standard. As is the case today, 
network access protection is assured. The primary 
site is equipped with the network management 
system, a digital cross connect device (DCCD) with 
five ports, a fully equipped enhanced (intelligent) 
multiplexer, and provisioned with spare circuit 
cards. (Figure 17-8) 

b. Site A . An "A" site is similar to a Primary site 
with the exception that it does not have a capabil- 
ity to monitor or control the network. Otherwise, 
it is equipped the same as a Primary site. (Figure 
17-9). 

c. Site B . A B B“ site is configured with an intel- 
ligent multiplexer terminating an FTS2000T-1 line. 
The multiplexer is fully equipped and spared, but 
there is no DCCD. (Figure 17-10) 

d. Site C . At a “C" site, there is a fully 
equipped and spared intelligent multiplexer 
which is interfaced to the FTS2000 network via a 
DCCD configured with two port cards. (Figure 17- 

ID 

e. Site D . A "D” site interfaces the FTS2000 
network via a DCCD configured for 3 ports. Each 
T-1 terminates in customer provided enhanced 
multiplexer equipment. To be connected to the 
NSAP T-1, the customer provided multiplexer must 
be approved by the FTS2000 vendor. In effect, this 
means using equipment designated by AT&T. 
(Figure 17-12) 

f. Site T-1 . A “T-l" site is equipped with an 
NSAP provided CSU (and spare). On the customer 
side of the CSU is customer terminating equip- 
ment, for example, the communications front end 
of a data processing facility, but with no NSAP pro- 
vided nor NSAP approved multiplexer. (Figure 
17-13) 

17.4.7.3 Architecture and Topology . There are 
two intelligent multiplexers approved for use un- 


der the NSAP contract modification: the 
ACCULINK 740 and ACCULINK 745 ("ACCULINK" is 
a registered trademark of AT&T). The 740 is a pro- 
grammable, time division, point-to-point, T-1 mul- 
tiplexer capable of combining analog, voice, and 
digital data (both synchronous and asynchronous) 
into a single composite data stream with T-1 fram- 
ing. The 745 is a T-1 switching multiplexer, which, 
along with the 740, is installed on the customer's 
premises by the FTS2000 vendor. The 745 supports 
the following network configurations: multipoint, 
drop and insert, and channel group bypass. 

The FTS2000 transition plan as currently envi- 
sioned is for Nascom to cutover its existing voice 
and data circuits at each location where the crite- 
ria for using FTS2000 services (not less than six 
DSOs to or from any one location). Figure 17-14 
represents a candidate architecture and topology 
for Nascom's FTS2000 network. (Again, this archi- 
tecture is based on the transition of existing eligi- 
ble circuits.) The figure portrays which FTS2000 
contract modifications are used on any given link 
and provides a representation of each node's ar- 
chitecture (site type(s)]. Note that NSAP, as imple- 
mented by Nascom, is limited to the 48 contiguous 
states of the Continental United States. Interna- 
tional circuits, circuits to Hawaii, Alaska, and the 
off-shore territories and possessions of the United 
States are not included. 

17.4.9.4 Schedule . Table 17-1 depicts the most 
current schedule for FTS2000 implementation. It 
should be noted that this schedule is subject to 
change as Engineering Changes and detailed cen- 
ter/site implementation plans are developed. 

17.5 ADVANCED NETWORK SYSTEMS DEVELOP- 
MENT ACTIVITIES 

17.5.1 ACTIVITIES OVERVIEW 

As indicated in paragraph 17.3.2, these include ac- 
tivities directly or indirectly related to the develop- 
ment and implementation of new Nascom data 
transport system(s) for the mid-1990's. These ac- 
tivities also include a variety of ongoing research 
and development projects, and SEAS contractor- 
tasked analysis studies. The following is a topical 
summary of advanced development-related activi- 
ties that are addressed in paragraph 17.5: 

a. EOS Communications (Ecom) 

b. GSFC FDDI LAN Development 

1 7.5.2 EOS COMMUNICATIONS (Ecom) PROJECT 

17.5.2.1 General . The Ecom project provides a 
unique ground-to-ground data transport system 
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Figure 17-11. Typical of Site C 
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Figure 17-12. Typical of Site D 
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Figure 17-13. Typical of Site T-1 
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Figure 17-14. Nascom FTS2000 Network Topology 


for operational EOS communications; Ecom is be- 
ing built to address EOS-specific requirements. (A 
high level summary of the EOS project is presented 
in paragraph 16.2.10.) The system provided by 
Ecom will transport forward link commands, re- 
turn link telemetry and payload science data, and 
operational data flowing between EDOS elements 
and between EDOS and the Distributed Active Ar- 
chive Centers (DAAC). Additionally, Ecom/Nascom 
will provide the communications between the EOS 
Operations Center (EOC) and the MO&DSD institu- 
tional systems (1) controlling and scheduling Space 
Network resources (the NCC) and (2) determining 
spacecraft orbit and attitude (the FDF) as well as 
the contingency support communications inter- 
faces with the GN, Wallops Orbital Tracking Sta- 
tion (WOTS), and the DSN. 

17.5.2.2 Goals and Requirements . The goals of 
Ecom are to: 

a. Implement an automated system maximiz- 
ing use of Commercial- Off-The-Shelf (COTS) 
equipment. 


b. Maintain compatibility with existing and 
enhanced versions of NASA institutional systems as 
needed to meet EOS requirements. 

c. Minimize life-cycle costs for implementa- 
tion, operation, and maintenance of the network. 

d. Allow for growth, adaptability to changing 
requirements, infusion of new technology, and 
upgrading interfaces throughout its life cycle. 

e. Prevent the unauthorized use of Ecom re- 
sources. 

f. Operate with a minimum of human inter- 
vention. 

In embracing these goals, some of the require- 
ments that Ecom will support are as follows: 

a. Transport traffic in a data driven mode be- 
tween specified locations. 
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Table 17-1. Nascom FTS2000 Project Schedule 


DATE 

LOCATION 1 

LOCATION 2 

NUMBER OF T1 CIRCUITS 

STATUS 

1003 



, ........ 


09/09 

GSFC 

JHU 


Completed 

11/03-08 

GSFC 

JSC 

(2) Equipment Upgrade and Transition 

Completed 

11/16 

GSFC 

Berkeley, CA 

(1)0 

Completed 

12/20 

GSFC J 

JPL 

(1)N 



■ ■ 




01/10 

GSFC 

JSC 

(1)N. (1)S 

Completed 

01/13 

GSFC 

JHU 

(1)N 

Completed 

02/07 

PASADENA** 


SDIS PIPE 


02/14 

JPL** 

San Diego, CA 

[([Hi 

Service Request Received 

02/14 

JPL** 

Palo Alto, CA 


Service Request Received 

02/15 

GSFC 

JHU 

(4) O, Change to Multimount 

Completed 

02/16 

GSFC 

Southbury* 

XI) N 


02/18 

GSFC 

MSFC* 

(1)N 

Completed 1 

EiH 

GSFC 

LaRC 

(1)N 

i" 1 ™ 1 ! 11 ummumm 


GSFC 

ARC (Moffett) 

(DN 

Completed i 

02/28 

GSFC 


(1)N 

tsss^^ 

03/17 

ARC 

NALF 

(DN 

Service Request Received 

03/25 

JPL 


(1)N 

Service Request Redeved 

03/29 

GSFC 

Berkeley, CA 

(1) Change to Multimount 

Completed 

03/29 

GSFC 

MSFC 

(1)N 

Completed 

04/19 

ARC 

NALF 

(1)0 

SRR 

04/25 

GSFC 

JPL 

(1)A 
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SRR 
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0)0 
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(1) N 
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IIESSSISBHHM 

0)3 

SRR 

05/05 
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(1>N 

SRR 
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<3)N 
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(DN 
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(DA 
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JSC* 
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05/17 
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JSC* 

All A 


05/23 

JSC 
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JSC 
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05/27 

GSFC 


(1)N 
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(DN 


06/02 

JSC* 

DFRF* 

(DA 


06/06 

JSC* 

JPL 



06/06 

JSC* 

ARC 



06/08 
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DFRF* 

<1)N 


06/13 

GSFC 

JPL 

JUS 


06/16 

GSFC 

OAFB 



TBD 

JSC 

WSC-STGT 

(1)N 


TBD 

GSFC 

WSC-STGT 

(DN 


TBD 

GSFC 

WSC-STGT 

(DA 


TDB 

GSFC 

KSC 

(DN 


TBD 

GSFC 

KSC 



TBD 

GSFC 

KSC 

(1)S 

i 

TBD 

GSFC 

KSC 

(1)S 

l 

TBD 

JPL 

Littleton CO 

(DN 

l 

TBD 

JSC* 

KSC 



TBD 

JSC* 

KSC 


IIHIHHHHHHHBli 

TBD 

JSC* 

KSC 

(DN 


TBD 

JSC* 

KSC 

(DS 


TBD 

JSC* 

KSC 



TBD 

JSC* 

KSC 

(DA 


TBD 

MSFC 

KSC 

(DN 


TBD 

MSFC 

KSC 

(DS 


TBD 

GSFC 

KSC 

(DN 
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b. Accommodate operations, simulations and 
testing on a concurrent basis. 

c. Comply with a standard addressing conven- 
tion per Open Systems Interconnection (OSI) Net- 
work Service Access Point addressing and Internet 
Protocol (IP). 

d. Route on Government Open System Inter- 
connection Profile (GOSIP) and IP. 

e. Perform protocol and address mapping. 

f. Expand to add new nodes. 

g. Expand modularly the number of physical 
interfaces and/or the aggregate throughput rate 
of any node. 

h. Provide network monitoring and control ca- 
pabilities to manage network topology and re- 
source allocation with display of same. 

i. Manage network operations, administra- 
tion, planning and security functions. 

j. Perform fault management functions inclu- 
sive of fault detection, isolation and resolution. 

k. Collect and report accounting and network 
utilization information. 

l. Ensure users comply with NASA Communi- 
cations Access Protection Policy and Guidelines 
and provide user authorization. 

17.5.2.3 Design Assumptions . Ecom makes cer- 
tain assumptions relative to network design. 
Some of these are stated in the following para- 
graphs: 

a. Science users will interface Ecom via Asyn- 
chronous Transfer Mode (ATM) via 100 Mbps 
multi-mode fiber, User-Network Interfaces 
(lOOUNIs), or Synchronous Optical Network 
(SONET) Optical Carrier (OC) 3c interfaces. For per- 
manent virtual circuits, the maximum single user 
rate is 28 Mbps. 

b. Real-time users will interface Ecom via Fiber 
Distributed Data Interface (FDDI), Ethernet II, or 

802.3 local area networks. 

c. The common carrier subsystem will use only 
full period, dedicated, leased common carrier ser- 
vices. DS3 service (44.736 Mbps) is the highest-rate 
tarriffed service available currently, and, conse- 
quently, is the highest-rate that is now used in the 
Ecom design. 


17.5.2.4 Topology and Architecture . A high level 
view of end-to-end data flows is depicted in Figure 
17-15. Figure 17-16 provides a conceptual archi- 
tecture representation for Ecom, its Node struc- 
ture, and the relationship of Ecom network man- 
agement functions to the EDOS management sys- 
tem. Ecom's design concept incorporates different 
subsystems for transport, network management, 
common carrier circuits, and engineering support. 
Using projected traffic data supplied by the EOS 
project, and after subjecting that data to network 
modeling and analysis, Ecom has developed can- 
didate topologies for support of the AM-1 mission 
(1998) and for the year 2002. These are depicted 
in Figures 17-17 and 17-18 respectively. These to- 
pologies incorporate the following design rules: 

a. The primary path between any two points is 
one hop. The secondary path is not more than two 
hops. 

b. Design utilization of available bandwidth is 
less than 80 percent. 

c. Each location will be supported by two di- 
verse physical paths. Sufficient redundancy is pro- 
vided in each path to enable recovery from a total 
path failure on one of the two paths. 

17-5.2-4.1 Transport Subsystem . The transport sub- 
system (TS) provides realtime, science, and frame 
encapsulator/decapsulator (FED) services. It also 
provide diagnostics equipment. TheTS is based on 
a backbone of ATM switches. Each of the three 
services utilizes this ATM backbone. 

a. Science users interface with Ecom through a 
fiber protect switch (FPS). The FPS enables Ecom to 
manually switch a science user from its primary 
ATM switch to a backup whenever the ATM inter- 
face (or entire switch) fails. Configuration items 
used to provide the science service are fiber pro- 
tect switch, ATM switch, and DS1 and DS3 patch 
panels. The architecture of the science service is 
depicted in Figure 17-19. 

b. Realtime users, given their more stringent 
availability and service restoral time requirements, 
must have automated recovery from all failures. 
Therefore, they interface with Ecom via Ethernet 
11/802.3 or FDDI LAN wiring hubs. The wiring hubs 
connect to routers which select the data path 
based on the layer 3 packets. ATM switches, in 
turn, combine the realtime with the science traffic, 
giving priority to router traffic. Configuration 
items used to provide the realtime service are the 
wiring hub, router, ATM switch (shared with sci- 
ence and FED services), and DS1 and DS3 patch 
panels (shared with other services). The architec- 
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Figure 17-19. Science Transport Architecture 


ture of the realtime service is depicted in Figure 
17-20. 

c. Frame encapsulator/decapsulator services 
are used to provide 4800-bit block data transfers 
with designated NASA institutional systems, e.g., 
the NCC, and CCSDS formatted data during pre- 
launch testing activities. The FED device is a devel- 
opment item for the Ecom project. It shares the 
following CIs with science and realtime services: 
wiring hub, router, ATM switch, and DS1 and DS3 
patch panels. 

17.5.2.4.2 Common Carrier Subsystem . The com- 
mon carrier subsystem (CCS) connects the elements 
of the TS together using leased circuits and ser- 


vices. The candidate topologies, depicted in Fig- 
ures 17-17 and 17-18, are simply candidates at this 
time. As the design matures, these topologies will 
be optimized. Baselining of the topology is sched- 
uled to occur at CDR, with refinement and opti- 
mization occurring thereafter, if required. In addi- 
tion, Ecom will support 9.6 kbps dial-up circuits 
from the NMCC and SEF out to each of the TS 
nodes. 

17.5.2.4.3 Network Management Subsystem . 
The network management subsystem (NMS) is 
comprised of central management equipment 
(CME), located at GSFC, and nodal network man- 
agement equipment. The CME monitors, man- 
ages, and controls the TS. It also monitors the CCS 
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via the TS using standard NM protocols and COTS 
software to the maximum extent possible. The 
CME performs these functions from the NMCC in 
Bldg 3/14. The CME is comprised of four operator 
stations (OS) and four laser printers. The CME in- 
terfaces with the EDOS Operations Management 
Function through the TS, with the NMCC console 
operators through the OSs, and with the M&O 
technicians through a human-machine interface 
(HMI) at each node. Communication between the 
CME and the TS uses the SNMP protocol to the 
maximum allowable extent. The CME will support 
Management Information Base (MIB) II as a mini- 
mum. The network management functions, listed 
in paragraph 17.5.2.2, are performed by the NMS. 
The Cl architecture of the NM is depicted in Figure 
17-21; the functions allocated to each OS are listed 
as part of the different CIs associated with each 
numbered OS. 

17.5.2.4.4 Engineering Support Subsystem . The 
engineering support subsystem (ESS) will be lo- 
cated in the Ecom Sustaining Engineering Facility, 
Building 28, GSFC. Though it is comprised mainly 
of CIs common to the TS and NMS, it is designated 
as a separate subsystem because it contains some 
additional CIs that are specific to engineering sup- 
port. The ESS includes three test nodes (test nodes 
are non-operational and do not interface the TS) 
which, taken together, contain at least one piece 
of every kind of equipment found in the TS. Suffi- 
cient equipment is provided to enable two of the 
test nodes to be configured to support the maxi- 
mum single stream data rate supported by the net- 
work, and so that alternate routing, switchover 
(failover), and service restoral scenarios can be 
tested. The ESS also supports the NMS function, 
and is to be equipped with one OS-1 or OS-2, one 
OS-3 or OS-4, one each high and low speed laser 
printers, two nodal human-machine interfaces, a 
maintenance terminal, two dial modems, one 
asynchronous data switch, and two modeling and 
development workstations. So equipped, the ESS 
can function as an emergency network control 
center in the event of a catastrophic failure of the 
NMCC. A functional depiction of the ESS equip- 
ment and its relationship to the TS is presented in 
Figure 17-22. 

17.5.2.5 Implementation Approach . Implemen- 
tation of the Ecom project is a responsibility of the 
NASA Communications Division, GSFC Code 540. 
To lead the project, Nascom has assigned a full 
time project manager at the "Assistant Chief for 
level. The project is being implemented in-house 
and lead by civil servant employees, predomi- 
nantly from the Advanced Development Section, 
Code 541.3, augmented by existing support con- 
tractor vehicles [Systems, Engineering, and Analy- 
sis Support (SEAS) and Network and Mission Oper- 


ations Support (NMOS) contracts] for engineering, 
project management, and Independent Test and 
Verification/Acceptance Testing (IT&V/AT) sup- 
port. Also assigned to the implementation man- 
agement team are civil servant and contract per- 
sonnel from Data Systems Assurance, Code 303, 
and the Logistics Management Section, Code 
535.3. 

Two in-house options for procurement of Ecom 
Configuration Items (Cl) (equipment and soft- 
ware) are under consideration: (1) use of the FTS 
2000 contract Network A (AT&T) service, if avail- 
able, and (2) competitive procurement through 
GSFC ADPE Procurement Branch, Code 243. COTS 
equipment and software are to be well defined by 
system PDR (early 1994) after which time procure- 
ment packages will be prepared in support of Re- 
quest for Proposal releases, if competitively pro- 
cured, or service orders placed under the FTS2000 
contract under provisions of Network A's Network 
Service Assurance Plan (NSAP), Level 2, if available. 
Where Development Configuration Items (DCI) 
may be required (e.g., equipment for encapsula- 
tion/decapsulation of the Nascom 4800-bit block 
and software implementing the NMCC/EDOS re- 
port generation function), the Ecom project will 
manage that development. The results of DCI 
PDRs and CDRs will be presented at the corre- 
sponding system level design review. Commercial 
communications carrier services in support of 
Ecom will be obtained using the approach de- 
scribed in Section 2 and Appendix F of the NSDP. 

17.5-2.6 Facilities . Nascom Interface Facilities (NIF) 
(see paragraph 3. 1.2. 5) will be established at each 
location supporting an Ecom network node. Re- 
mote nodes will be provided staffing by Nascom, 
except for the East Windsor spacecraft integration 
and test facility node which will be operated and 
maintained by the spacecraft contractor. As 
Nascom attended facilities, they also meet the cri- 
teria of a Nascom Point of Presence facility (see 
paragraph 3.1.2.4). To house the NIFs, physical fa- 
cilities are required at each location where an 
Ecom node will be activated. The Ecom Facility 
Plan and Utilization document, at this stage in the 
project, provides only "typical" requirements in- 
formation for an Ecom facility: 1050 square feet 
for Ecom equipment, common carrier interface 
equipment, and a maintenance and operations 
work area. "Candidate" floor plans for a network 
node and the Ecom SEF are depicted in Figures 1 7- 
23 and 17-24, respectively. Figure 17-25 depicts 
the NMCC as currently planned. NIFs, the NMCC, 
and the SEF will be established and tested for ac- 
ceptance into the network as indicated in Table 
17-2. 
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Table 17-2. Ecom Nodes and Activation 

Schedule 


NODE 

SYSTEM TEST 
SCHEDULE 

Install 1 


GSFC /NMCC 

3rd Quarter, FY96 

GSFC /EOC 

3rd Quarter, FY96 

WSC/EDOS DIF 

3rd Quarter, FY96 

Fairmont WV/EDOS DPF 

3rd Quarter, FY96 

East Windsor, NJ/S/C ITF 

3rd Quarter, FY96 

VAFB, CA/LF 

3rd Quarter, FY96 

Install II 


GSFC /SEF 

1st Quarter, FY97 

Sioux Falls, SD/EDC 

1st Quarter, FY97 

JPL,DAAC & IP GW 

1st Quarter, FY97 

LaRC/DAAC 

1st Quarter, FY97 

Install III 


MSFC/DAAC 

4th Quarter, FY97 


17.5.2.7 Staffing . The Ecom Maintenance and 
Operations Management Plan indicates that 
Nascom currently intends to provide sufficient 
maintenance and operations (M&O) technicians at 
each of the remote nodes, except for the EWNJ 
node which will be supported by Martin Marietta 
Corporation, to provide round the clock coverage, 
365 days a year. At GSFC, sufficient M&O techni- 
cians will be added to the NMOS contractor's au- 
thorized staffing level to provide NMCC console 
operations personnel on a full period basis and to 
provide M&O technicians to cover the EOC node, 
NMCC, and SEF on a dispatch basis. For the Install 
I and II facilities, staffing will be phased in over 
two cycles, i.e., about half of the Install I M&O staff 
will be hired, trained, and assigned to their respec- 
tive duty locations during the Install I period; the 
remaining M&O technicians for Install I sites will 
be supplied during the Install II period. In a similar 
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Figure 1 7-22. ESS Equipment and Relationship to TS 


fashion, Install II site personnel will be phased in 
during the periods of Installs II and III. Install III 
M&O staff will be provided during the Install III 
period. 

17.5.2.8 Training . The Ecom Training Plan indi- 
cates that the initial formal training will be pro- 
vided to the M&O staff, the installation contrac- 
tor's installation team (for the direct procurement 
through Code 243 option only), the IT&V/AT team, 
and to persons from the Network Test and Train- 
ing Facility (NTTF) who will be responsible for 
follow-on training. For the M&O staff, initial for- 
mal training is followed by a period of On-the-Job 
Training (OJT) conducted by members of the en- 
gineering/installation team. 

17.5.2.9 Schedule . The Ecom project completed 
the System Requirements Review phase on Febru- 
ary 26, 1993, when the Nascom Project Review 
Board Chairman issued a formal authorization to 
proceed with the design phase. The Project pre- 
sented is System Design Review on February 7, 
1994. Information from the Ecom master sched- 
ule with EOS and EDOS major milestones shown 


for correlation purposes, is depicted in Figure 
17-26. 

17.5.2.10 Observation . Ecom represents a para- 
digm shift in the way Nascom provides operational 
communication services to flight missions and oth- 
er users. The network will be data driven, i.e., will 
transport data from (ground data system) source 
to (ground data system) sink, using information 
contained in the header of the data packet. There 
will be no need to externally schedule and config- 
ure the network resources required for support of 
each service. The network will be comprised of 
COTS equipment and software in so far as possible. 
Standard protocols, e.g., ones selected from the 
GOSIP suite and IP, will be employed. The network 
will be highly automated, performing routine net- 
work management functions without need of hu- 
man intervention. Also of significance, Ecom is 
Nascom's first new network to be implemented 
under the guidelines established in NASA's Deci- 
sion Memorandum No. 25: the network is funded 
by, designed to the requirements of, and dedi- 
cated in providing its communications services to 
the EOS program. 
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Figure 1 7-23. Conceptual Layout of an Ecom Network Node 


17.5.3 FACILITY AND RESOURCE MANAGER 
(FARM) 

The Facility and Resource Manager (FARM) Project 
has been formed with the goal to provide auto- 
mated network management of the NASA Com- 
munications (Nascom) Division (Code 540) world- 
wide network. The FARM project will functionally 
re-engineer the automated control and status ca- 
pabilities to provide automated command, moni- 
tor and management interface capabilities of all 
Nascom communication equipment located at 
GSFC, JSC, MSFC, and NGT. All functions of the 
Nascom Network will be investigated for possible 
inclusion in the command architecture design. 


The FARM will emphasize utilization of COTS Net- 
work Management Systems, State-of-the-art Tech- 
nology and Standards. The project, initiated in De- 
cember 1993, will begin with a functional require- 
ments analysis and continue through operational 
acceptance at the Nascom Operational Readiness 
Review (ORR). 

The FARM will utilize a phased implementation 
approach. Phase I will concentrate on interfacing 
to and controlling the new Digital Matrix Switch 
(DMSR). The remaining content of Phase I and the 
follow-on phases will be determined by the results 
of the initial requirements analysis and 
prototyping efforts. Phase I is scheduled for com- 
pletion in March 1995. 
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Figure 1 7-24. Conceptual Layout of Ecom SEF 
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APPENDIX B 
GLOSSARY 


ACRONYM 

DEFINITION 

A-G 

Air-to-G round 

AC 

Alternating Current 

ACA 

Canadian Space Agency, Alberta 

ACAN 

Army Command and Administrative Network 

ACRV 

Assured Crew Return Vehicle 

ACT 

Australian Capital Territory 

ADPE 

Automatic Data Processing Equipment 

AE 

Building Designator at Cape Canaveral Air Force Station 

AED 

Analog Event Distribution Subsystem 

AERO 

Aerosols 

AFB 

Air Force Base 

AFSC 

Air Force Systems Command 

AFSD 

Air Force Space Division 

AGO 

Santiago (3-letter Designator) 

AGVS 

Air-ground Voice Subsystem 

AIS 

Automated Information Systems 

AL 

Alabama 

ALT 

Altimetry 

AMS 

Administrative Message System 

ANC 

Alternate Network Connectivity 

ANT 

Antigua Island, Eastern Range Station (3-letter Designator) 

ANZCAN 

Australia, New Zealand, Canada Subcable 

AOA 

Abort-Once-Around 

AP 

Applications Processor 

APLS 

ATDRS Position Location System 

APM 

Attached Pressurized Module 

ARA 

Area Routing Assembly 

ARC 

Ames Research Center 

APL 

Applied Physics Laboratory 

ART 

Advanced Research Technology 

ASC 

American Satellite Corporation 
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ACRONYM 

DEFINITION 

ASCII 

American Standard Code for Information Interchange 

ASCR 

Ames Stripchart Recorder 

ASO 

Application Services Objects 

ASRS 

Automated Support Requirements System 

AT 

Acceptance Test 

AT&T 

American Telephone and Telegraph 

ATC 

Australian Telecommunication Commission 

ATDRSS 

Advanced Tracking and Data Relay Satellite System 

ATM 

Asynchronous Transfer Mode 

ATP 

Acceptance Test Plan; Acceptance Test Procedures 

AVD 

Alternate Voice/Data 

AXAF 

Advanced X-Ray Astrophysics Facility 

AXAF-S 

AXAF Spectroscopy 

AZ 

Arizona 

b/s 

Bits per Second 

BALUN 

Balanced to Unbalanced 

BATSE 

Burst and Transient Source Experiment (Gamma Ray Observatory) 

BCT 

Buffered Communications Terminal 

BDA 

Bermuda GN Station (3-letter Designator) 

BDS 

Baseline Data System 

BED 

Block Error Detector 

BER 

Bit Error Rate 

BF 

Block Formatter 

BFX 

Bulk File Exchange 

BISDN 

Broadband Integrated Services Digital Network 

BLT 

Greenbelt Ground Network Station (3-letter Designator) 

BOA 

Basic Ordering Agreement 

BOOTMSU 

warm start of the MSU applications from the COW 

bps 

Bits per second 

BRTS 

Bilateration Ranging Transponder System 

BSCD 

Baseline System Concept Document 

BWG 

Beam Wave Guide 

C&P 

Chesapeake and Potomac Telephone Company 

C&T 

Communications and Tracking 

C&W 

Cable and Wireless (Bermuda) 
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ACRONYM 

CA 

CAB 

CADH 

CAL 

CAN 

CANBER 

CAP 

CBD 

CCAFS 

CCB 

CCBTS 

CCC 

CCDTS 

CCI 

CCIM 

CCITT 

CCM 

CCNIF 

CCQ 

CCRF 

CCS 

CCSDS 

CCT 

CCTCF 

CCTV 

CD&SC 

CDA 

CDB 

CDF 

CDHF 

CDL 

CDMA 

CDOS 

CDR 

CDSCC 


DEFINITION 

California 

Circuit Assurance Block 
Command and Data Handling 
COW Alert Processing Task 

Canberra 26-meter Deep Space Network Station (3-letter Designator) 

Canada Bermuda Cable Designator 

Command Acceptance Pattern 

Commerce Business Daily 

Cape Canaveral Air Force Station 

Configuration Control Board 

Common Carrier Broadcast Data Transmission Service 

Cape Communications Control; Central Computer Complex (Eastern Range) 

Common Carrier Domestic Satellite Transponder Service 

Commercial Carrier Interface 

Command Computer Input Multiplexer 

International Telegraph and Telephone Consultative Committee 

COW Baseline Configuration Change Task 

Cape Canaveral Nascom Interface Facility 

COW Command and Query Task 

Consolidated Communications Recording Facility 

Common Carrier Subsystem 

Consultative Committee for Space Data Systems 

Central Communications Terminal (Jet Propulsion Laboratory) 

Communications Circuit Technical Control Facility 

Closed-circuit Television 

Communication Distribution & Switching Center 
Command and Data Acquisition 
COW Database Manager Task 
Communications Data Formatter 

Central Data Handling Facility (Upper Atmosphere Research Satellite) 

COW Delogging Task 
Code Division Multiple Access 
Customer Data Operations System 
Critical Design Review 

Canberra Deep Space Communications Complex 
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ACRONYM 

DEFINITION 

CES 

Control Electronics System; COW Expert System Task 

CFR 

Concept Feasibility Report 

CFS 

Continental Telephone's Federal Services Division 

CGS 

CCSDS Ground Subnetwork 

CHC 

COW Checkpoint Configuration Change Task 

CHEM 

Chemistry 

CHP 

Command History Printer 

Cl 

Configuration Items 

CIF 

COW/MSU Interface Task 

CIN 

COW Initialization and Recovery Task 

CIS 

Communications Interface System 

CITF 

CDOS Integration and Test Facility 

CLD 

COW Line Indicator Display Task 

CLG 

COW Logging Task 

CLS 

Communications Line Switching 

CLUSTER 

Plasma Turbulence Laboratory (ISTP Spacecraft) 

CME 

Central Management Equipment 

CMG 

COW Message Generator Debug Tool 

CMS 

Command Management System; Consolidated Management System 

CNES 

Centre National D'Etudes Spatiales (National Center for Space Studies, France) 

CNIF 

Canberra Nascom Interface Facility 

CNV 

Cape Canaveral (Eastern Range) Station (3-letter Designator) 

CO 

Central Office; Colorado 

COA 

COW Operator Assistance Task 

COBE 

Cosmic Background Explorer 

Codec 

Coder/Decoder 

COM 

Computer Output Microfilm 

COMMGR 

Communications Manager 

ComPlus 

Communications Control System 

COMPTEL 

Compton Telescope (Gamma Ray Observatory) 

COMS 

CDOS Operations Management System 

COMSAT 

Communications Satellite Corporation 

COMSEC 

Communications Security 

COMSTAR 

Communications Satellite 
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ACRONYM 

COMTEL 

CONS 

CONVTXT 

COP 

COR 

COS 

COSTR 

COTS 

COW 

CPE 

CPP 

CPU 

CRAF 

CRT 

CSA 

CSAM 

CSB 

CSE 

CSF 

CSO 

CSR 

CSS 

CSTC 

CSTS 

CTofCC 

CTA 

CTCCo 

CTMC 

CTNE 

CTO 

CTP 

CTS 

CTV 

CU 

CWA 

CWG 


DEFINITION 

Manufacturer of Nascom Integrated Services Digital Network Time Division Multiple 
Access Systems 

Console Subsystem 
Converts ASCII Text Files 
Co-orbiting Platform 
Contracting Officer's Representative 
COW Operator Stations Task 
Collaborative Solar-Terrestrial Research 
Commercial Off-The-Shelf 
Combined Operator Workstation 
Customer Provided Equipment 
Capacity Projection Plan 
Central Processing Unit 
Comet Rendezvous Asteroid Flyby 
Cathode Ray Tube 

Communications Service Authorization 
Carrier Services Advisory Message 
Carrier Selection Board, Circuit Selection Board 
Configuration and Switching Equipment 
Control and Simulation Facility 
Computer Security Officials 
Communications Service Request 

Communications Services Section; Control and Status System 
Consolidated Space Test Center 
Control Subsystem Transfer Switch 
Continental Telephone of California Company 
Compatibility Test Area 

Continental Telephone of California Company 

Communications Terminal Modular Controller 

Compania Telefonica Nacional De Espana 

CarrierTerminal Office 

CircuitTerminating Package 

COW Troubleshooting Task 

Compatibility Test Van 

COW Common Units 

Cryptographic Work Area 

Communications Working Group 
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ACRONYM 

DEFINITION 

CWL 

Cable and Wireless, Ltd. 

CXR 

Commercial Carrier 

DAA 

DoD Approving Authority 

DAAC 

Distributed Active Archive Centers 

DAF 

Data Acquisition Facility 

DAVID 

Digital Above Video 

DBCI 

Data Base Change Instruction 

DC 

Destination Channel 

DC 

Direct Current; District of Columbia 

DCA 

Defense Communications Agency 

DCC 

Data Computation Complex 

DCCD 

Digital Cross Connect Device 

DCE 

Data Circuit Terminating Equipment 

DCF 

Data Capture Facility (Goddard Space Flight Center) 

DCI 

Development Configuration Items 

DCMS 

Defense Contract Management Support 

DCR 

Daily Communications Reports 

DCS 

Digital Matrix Switch Control System; Display and Control System 

DCS/U 

DCS Upgrade 

DCSU 

DCS Upgrade 

DDCS 

Data Distribution and Command System 

DDD/SDD 

Digital Display Driver/Subchannel Data Distributor 

DDGT 

Digital Data Group Terminals 

DDHS 

Dump Data Handling Subsystem 

DDPS 

Digital Data Processing System 

DDS 

Dataphone Digital Service; Digital Data Service; Discrete Display Subsystem 

DEC 

Digital Equipment Corporation 

DEMUX 

Demultiplexer 

DFRF 

Dryden Flight Research Facility 

DGIB 

DSN/GSFC Interface Block 

DHC 

Data Handling Center 

DHE 

Data Handling Equipment 

DIF 

Data Interface Facility 

DIF 

Domsat Interface Facility (Goddard Space Flight Center) 

DIS 

Data Interface System 

DITAC 

Department of Industry, Technology, and Commerce 
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ACRONYM 

DEFINITION 

DKR 

Dakar GN Station (3-letter Designator) 

DKS 

Digital Keyset 

DLMS 

Data Link Monitoring System; Downlink Monitoring System 

DLR 

Deutsche Forschungs und Versuchsanstaltfuer Luft und Raumfahrt 
(Research Agency for Aerospace Technology, Germany) 

DLSM 

Data Link Summary Message 

DMA 

Direct Memory Access 

DMF 

Distributed Management Function 

DMR 

Detailed Mission Requirements 

DMS 

Digital Matrix Switch 

DMSR 

Digital Matrix Switch Replacement 

DoD 

Department of Defense 

Domsat 

Domestic Satellite 

DOS 

Disk Operating System 

DPF 

Data Production Facility 

DRRTS 

Digital Receive, Record, and Transmit System 

DSC 

Data Switching Center (Western Range, VAFB) 

DSCC 

Deep Space Communications Complex 

DSCIM 

Display Select Computer Input Multiplexer 

DSM 

Data Support Manager; Data Systems Manager 

DSN 

Deep Space Network 

DSS 

Deep Space Station 

DSS 

Digital Switching System; Distribution Switching System 

DSTL 

Data Systems Technology Laboratory 

DSU 

Data Service Unit 

DTE 

Data Terminal Equipment 

DTI 

Data Transmission Interface 

DTS 

Digital Television Subsystem; Digital Transmission System 

DTTS 

Data Transmission Test Set 

E 

Electronics 

E&O 

Building Designator at Cape Canaveral Air Force Station 

E-BUSS 

Electronics Buss 

EAFB 

Edwards Air Force Base 

ECC 

Emergency Communications Center (Goddard Space Flight Center) 

ECIO 

Experiment Computer Input Output (Spacelab) 
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ACRONYM 

Ecom 

ECOS 

ECS 

EDC 

EDOS 

EER 

EFTO 

EGRET 

El 

EIA 

ELV 

EMAIL 

EMAT 

ENTEL 

EOC 

EOM 

EOR 

EOS 

EPS 

ER 

ERBS 

EROS 

ES 

ES-1 

ES-2 

ESA 

ESC 

ESDIS 

ESF 

ESMC 

ESOC 

ESP 

ESS 

ESTL 

ETS-VI 


DEFINITION 

EOS Data Operations System Communications 

Engineering Channel Operating System 

Error Correction and Switching System 

Earth Resources Observation Satellite Data Center 

EOS Data and Operations System 

Engineering Economics Research, Inc. 

Encrypt For Transmission Only 

Energetic Gamma Ray Experiment Telescope (Gamma Ray Observatory) 

Equipment Interface 

Electronic Industries Association 

Expendable Launch Vehicle 

Electronic Mail 

Ecom Modeling, Analysis, and Testbed 
Empresa Nacional de Telecommunications (Chile) 

EOS Operations Center 
End of Message; End-of-Mission 
Expedited Operations Requirements 
Earth Observing System 
Energetic Particle Sensor 
Eastern Range 

Earth Radiation Budget Satellite 

Earth Resources Observation Satellite 

Earth Station 

Earth Station One 

Earth Station Two 

European Space Agency 

Engineering Support Center 

Earth Science and Data Information System 

Enhanced Standard Format 

Eastern Space and Missile Center 

Earth Station Owners Consortium; European Space Operations Center 

Equatorial Science Phase 

Engineering Support Subsystem 

Electronic Systems Test Laboratory at JSC 

Engineering Test Satellite-VI 



GLOSSARY B-8 


ACRONYM 

EURECA 

EUTELSAT II 

EUVE 

EWNJ 

F/L 

FAA 

FAR 

FARM 

FAST 

FCC 

FDDI 

FDF 

FDM 

FDX 

FE 

FEC 

FED 

FEL 

FES 

FGB 

FIFO 

FIMS 

FIPS 

FIRMR 

FL 

FM 

FOLAN 

FOT 

FPS 

F&PR 

FPS 

FPSO 

FRF 

FSG 

FSR 


DEFINITION 

European Retrievable Carrier 
European Telecommunications Satellite II 
Extreme Ultra Violet Explorer 
East Windsor, New Jersey 
Forward Link 

Federal Aviation Administration 
Federal Acquisition Regulations 
Facility and Resource Manager 
Fast Auroral Snapshot Explorer 
Federal Communications Commission 
Fiber Distributed Data Interface 
Flight Dynamics Facility 
Frequency Division Multiplex 
Full Duplex 
Front End 

Federal Electric Corporation 
Frame Encapsulator/Decapsulator 
First-element Launch (Space Station Freedom) 

Front End Support 

Functional Energy Block (English translation of Russian Term) 
First-in-First-out 

Fault Isolation Monitoring System 

Federal Information Processing Standard 

Federal Information Resources Management Regulations 

Florida 

Frequency Modulation 

Fiber Optic Local Area Network 

Fiber Optic Transceiver; Flight Operations Team 

Fiber Protect Switch 

Functional and Performance Requirement 
Flight Planning System 
Flight Project Support Office 

Flight Research Facility (3-letter Designator) at Dryden 
Future Service Growth 
Flight Support Request 
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ACRONYM 

DEFINITION 

FTAM 

File Transfer, Access, and Management 

FTGT 

First TDRSS Ground Terminal 

FTH 

Fort Huachuca Station (3-letter Designator) 

FTS 

Federal Telecommunications System 

FWV 

Fairmont, West Virginia 

FY 

Fiscal Year 

GA 

Georgia 

GAO 

General Accounting Office 

GCF 

Ground Communications Facility 

GDS 

Goldstone Deep Space Network Station (3-letter Designator); 
Group Display Subsystem 

GDSCC 

Goldstone Deep Space Communications Complex 

GEAM 

GE American Communications, Inc. 

GE Americom 

GE American Communications, Inc. 

GEOTAIL 

Geomagnetic Tail Laboratory 

GFE 

Government Furnished Equipment 

GGS 

Global Geospace Science 

GGTS 

Ground-to-ground Transport System 

GHB 

Goddard Handbook 

GHIT 

Goddard Space Flight Center High Density Inventory Tape 

GHz 

Gigahertz 

GIB 

Group Interface Board 

GMI 

Goddard Space Flight Center Management Instruction 

GMS-5 

Geostationary Meteorological Satellite-5 

GN 

Ground Network 

GOES 

Geosynchronous Operational Environmental Satellite 

GOSIP 

Government Open System Interconnect Profiles 

GPIB 

General Purpose Interface Board 

GOSA 

Ground Data System Assurance 

GPOC 

German Payload Operations Center 

GPS 

Global Positioning Satellite 

GRO 

Gamma Ray Observatory 

GRTS 

Goddard Space Flight Center Real-time Computing System (4-letter Designator); 
GRO Remote Terminal System 

GSA 

General Services Administration 

GSE 

Ground Support Equipment 

GSFC 

Goddard Space Flight Center 
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ACRONYM 

DEFINITION 

GSOC 

German Space Operations Center 

GSSR 

Goldstone Solar System Radar 

GSTS 

Goddard Space Flight Center Message Center (4-letter Designator) 

GTC 

General Telephone Company 

GTNDP 

GSFC Telecommunications Network Development Plan 

GW 

Gateway 

HAWTELCO 

Hawaiian Telephone Company 

HDDR 

High Density Data Recorders 

HDQ 

High-speed Data Queue 

HDR 

High-data Rate 

HORR 

High-data Rate Recorder 

HDRS 

High-data Rate System 

HDX 

Half-duplex 

HEAO 

High Energy Astrophysics Observatory 

HEO 

High-earth Orbiter 

HEPAD 

High-Energy Proton and Alpha Detector 

HI 

Hawaii 

HMI 

Human-Machine Interface 

HOSC 

Huntsville Operations Support Center 

HP 

Hewlett-Packard 

HQ 

Headquarters 

HRDLM 

High-Rate Data Link Monitor 

HRDM 

High-rate Demultiplexer 

HRFL 

High-rate Forward Link 

HRM 

High-rate Multiplexer 

HS 

High-Speed 

HSD 

High-speed Data 

HSDS 

High-speed Data System 

HSSI 

High Speed Serial Interface 

HVAC 

Heating, Ventilation, and Air Conditioning 

Hz 

Hertz 

1 

Incident (signal) 

I/O 

Input/Output 

IBDDR 

Interbuilding Data Dissemination Resource 

IBDTS 

Interbuilding Data Transfer System 
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ACRONYM 

DEFINITION 

IBS 

International Business Service 

1C 

Input Controller 

ICC 

Institutional Communications Company; Instrument Control Center; 
Inter-Center Communications, Inc. 

ICCWG 

Intercenter Communications Working Group 

ICD 

Interface Control Document 

ICE 

International Cometary Explorer 

ICF 

Instrument Control Facilities 

ICLU 

Interbuilding Communication Link Upgrade 

ICV 

Intercenter Vector 

ID 

Identifier 

l-DIF 

Interim Data Interface Facility 

IF 

Intermediate Frequency 

IFL 

Interfacility Link (between WSGT/NGT and STGT) 

IGF 

Image Generation Facility 

IGSE 

Instrument Ground Support Equipment (Gamma Ray Observatory) 

IGY 

International Geophysical Year 

ILS 

Integrated Logistics Support 

ILSP 

Integrated Logistics Support Plan 

ILT 

Interface Level Translator 

IMP 

International Monitoring Platform 

INPE 

Intitutode Pequisas Espacias-Brazil 

INSF 

International Network Support Forum 

INTA 

Instituto Nacional deTecnica Aerospacial 

INTELSAT 

International Telecommunications Satellite Consortium 

IOU 

Input-Output Unit 

IP 

International Partner; Internet Protocol 

IPD 

Information Processing Division (Goddard Space Flight Center) 

IRC 

International Record Carrier 

IRD 

Interface Requirements Document 

IRIG 

Interrange Instrument Group 

IRIS 

Italian Research Interim Stage 

IRU 

Integrated Recovery Utility 

ISAS 

Institute of Space and Astronautical Science 

ISC 

Integrated Secure Communications 
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ACRONYM 

DEFINITION 

ISCS 

Integrated Secure Communication System 

ISDN 

Integrated Services Digital Network 

ISI 

Information Services, Incorporated 

ISO 

International Standard Organization 

ISPR 

International Standard Payload Rack 

1ST 

Instrument Support Terminals 

ISTP 

International Solar-Terrestrial Physics 

IT&V/AT 

Independent Test and Verification/Acceptance Testing 

ITP 

Integration and Test Plan 

ITS 

Intelligent Terminal System 

ITT 

International Telephone and Telegraph 

ITTC 

International Telegraph and Telephone Consultative Committee 

ITU 

InputTerminal Unit 

IUE 

International Ultraviolet Explorer 

IUS 

Inertial Upper Stage 

JEM 

Japanese Experiment Module 

JEM EF 

Japanese Experiment Module Exposed Facility 

JHU 

John Hopkins University 

JMRTS 

JSC-MSFC Redundant Transmission System 

JOI 

Jovian Orbit Insertion 

JOP 

Joint Operations Procedure 

JNOC 

JPL Network Operational Control 

JPL 

Jet Propulsion Laboratory 

JSC 

Johnson Space Center 

K 

Kilo (thousand) 

CaSA 

Ka-band Single Access 

kb/s 

Kilobits per Second 

kbps 

Kilobits per Second 

KDP 

Keyboard Display Printer 

KEE 

Knowledge Engineering Environment 

kg 

Kilogram 

kHz 

Kilohertz 

KIDS 

Kennedy Integrated Data System 

km 

Kilometer 

KMRTS 

Kennedy-Marshall Redundant Transmission System 

KPT 

Kanea Point Station (3-letter Designator) 

KSA 

Ku-band Single Access 
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ACRONYM 

KSC 

KuSA 

KuSP 

kva 

KWJ 

LACN 

LAGEOS 

LAN 

LaRC 

LCC 

LDR 

LED 

LeRC 

LF 

LISP 

LLTDS 

LMSC 

LOR 

LP 

LPS 

LRBS 

LRP 

LRU 

LSD 

LSDS 

LSR 

LSS 

LTAS 

LTP 

M&O 

MA 

MACC 

MACS 

MACSU 

MAD 

MAF 

MAN 

MAP 


DEFINITION 

Kagoshima Space Center; Kennedy Space Center 
Ku-band Single Access 
Ku-band Signal Processor 
Kilovolt Ampere 

Kwajalein Island Station (3-letter Designator) 

Local Area Communications Network 

Laser Geodynamic Satellite 

Local Area Network 

Langley Research Center 

Launch Control Center (Kennedy Space Center) 

Low-data Rate 
Light-emitting Diode 
Lewis Research Center 
Launch Facility 
List Processing 

Launch and Landing Trajectory Data System 

Lockheed Missiles and Space Company 

Line Outage Recorder 

Line Processor 

Launch Processing System 

Low Rate Black Switch 

Long-range Plan 

Line Replaceable Unit 

Logistics Supply Depot 

Low-speed Data System 

Launch Support Request; Launch Support Requirements 

Launch Support Structure, Service Module (English translation of Russian Term) 
Launch Tracking and Acquisition System; Launch Trajectory Acquisition System 
Long Term Plan 
Maintenance and Operations 
Multiple Access 

Multiple Application Control Center 
Multiplexer/Demultiplexer Automatic Control System 
Multiplexer/Demultiplexer Automatic Control System Upgrade 
Madrid 26-meter Deep Space Network Station (3-letter Designator) 

Multiple Access, Forward Link 
Metropolitan Area Network 
Maintenance Administration Position 
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ACRONYM 

MASM 

MB 

Mb/s 

MBI 

Mbps 

MBS 

MBSU 

MCC 

MCCC 

MCI 

MCMD 

MCS 

MCU 

MD 

MDAC 

MDD 

MDDF 

MDM 

MDMR 

MDS 

MDSCC 

ME 

MER 

MeV 

MGS 

MHL 

MHS 

MHU 

MHY 

MHz 

Ml 

MIB 

MIDDS 

MIF 

MIL 


DEFINITION 

Macro Assembler 
Manned Base 
Megabits per Second 

Multibus Interface; MSU Backup Operator Interface Task 
Megabits per second 
Mobile Base System 
Main Bus Switching Unit 

Mission Control Center; Mission Control Consoles 

Mission Control and Computing Center (Jet Propulsion Laboratory) 

Microwave Communications, Incorporated 

MSU Console Command Task 

Microprocessor System 

MSU/COW Common Utility Modules 

Maryland 

McDonnell Douglas 

MSU Database Distribution Task 

Minimum Delay Data Format 

Multiplexer/Demultiplexer 

Multiplexer/Demultiplexer Replacement 

MSU Data Simulator Task 

Madrid Deep Space Communications Complex 

Maine 

Mission Evaluation Room 

Million Electron Volt 

Mars Global Surveyor 

MSU High-speed Logging Task 

MSU High-speed Switching Task 

MSU High-speed Utility Task 

MSU Hybrid Data Task 

Megahertz 

Michigan 

Management Information Base 
Meteorological Interactive Data Display System 
MSU/COW Interface Task 

Merritt Island Ground Network Station (3-letter Designator) 
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ACRONYM 

MIL-71 

MIN 

MLA 

MMG 

MMI 

MMS 

MM/TMS 

MNIF 

MOAA 

MO&DS 

MO&DSD 

MOC/DSC 

MODEM 

MODLAN 

MODNET 

MODSIN 

MOI 

MOM 

MOSP 

MOU 

MOW 

MPC 

MPT 

MRR 

MSCC 

MSCN 

MSFC 

MSFN 

MSM 

MSOCC 

MSO 

MSP 

MSS 

MSU 

MT 


DEFINITION 

Deep Space Network Test Facility at Kennedy Space Center 
MSU Initialization and Recovery Task 
Merritt Island Station (3-letter Designator) 

MSU Message Generator Debug Tool 
Man Machine Interface 
Multimission Modular Spacecraft 

Megamux Plus TDM and Megamux Transport Management System 

Madrid Nascom Interface Facility 

MSS Operator's Advisor and Assistant 

Mission Operations and Data Systems 

Mission Operations and Data Systems Directorate 

Mission Operations Computer/Dynamic Standby Computer 

Modulator/Demodulator 

Mission Operations Division Local Area Network 

MO&DSD Operational/Development Network 

Mission Operations and Data Systems Network 

Mars Orbit Insertion 

Missions Operation Manager 

Mission Operations Support Plan 

Memorandum of Understanding 

Mission Operations Wing 

Mission Planning Center 

Mission Planning Terminal 

Mission Requirements Request 

Manned Space Control Center 

Manned Space Communications Network 

Marshall Space Flight Center 

Manned Space Flight Network 

Mission Support Manager 

Multisatellite Operations Control Center (Goddard Space Flight Center) 
Management System Operation 
Modular Switching Program 

Message Switching System; Multispectral Scanner (Landsat Experiment) 
Main Storage Unit; Message Switching System Upgrade 
Mobile Transponder 
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ACRONYM 

MTBF 

MTC 

MTL 

MTTR 

MU 

MUDUMP 

MUX 

MVL 

N2 

NA 

NALF 

NAS 

NASA 

NASA HQ 

Nascom 

N as com II 

NASCOP 

NASDA 

NAUG 

NBS 

NCC 

NCIC 

NCG 

NCP 

NCPS 

NCS 

NDC 

NDEEC 

NDI 

NEAP 

NED 

NES 

NESDIS 

NESS 

NEST 


DEFINITION 

Mean-Time-Between-Failures 

Man-Tended Capability 

Mount Lemmon Station (3-letter Designator) 

Mean-Time-To-Restore 
MSU Common Units 
MSU Task Dump Utility 
Multiplexer 
Majority Voting Logic 

NASA Communications System for the Space Station Freedom Era (Nascom II) 
Network Adapters 

Naval Auxiliary Landing Field (Crows Landing, CA) 

Flight Dynamics Facility Computer 
National Aeronautics and Space Administration 
NASA Headquarters 
NASA Communications 

NASA Communications System for the Space Station Freedom Era 
NASA Communications Operating Procedures 
National Space Development Agency (Japan) 

Nascom Augmentation 

National Bureau of Standards 

Network Control Center 

Networks Communications Interface Common 

Network Control Group 

Network Consolidation Program 

Network Command Process System 

National Communications System 

Network Development Center (Goddard Space Flight Center) 

Nascom II Development, Engineering, and Emergency Support Center 

Nondevelopment Item 

Nascom Evolution Action Plan 

Network Encoder/Decoder 

Nascom Event Schedule/Scheduling 

National Environmental Satellite Data and Information Service 
National Environmental Satellite Service 
Network Engineering Support Team 
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ACRONYM 

DEFINITION 

NETEX 

Network Executive 

NGT 

NASA Ground Terminal (White Sands) 

NGTC 

National Gateway Telecom 

Nil 

Nascom II 

NIF 

Nascom Interface Facility 

NIM 

Network Integration Manager 

NIP 

Network Interface Processor 

NIS 

Nascom Interface System 

NISDN 

Nascom Integrated Services Digital Network 

NISI 

Network and Information Systems 

NJ 

New Jersey 

NLV 

Nippon Launch Vehicle 

NM 

Network Management; New Mexico 

NMCC 

Nascom II Network Management; Network Management Control Center 

NMI 

NASA Management Instruction 

NMOS 

Network and Mission Operations Support 

NMP 

Network Management Processor 

NMS 

Network Management Service; Network Management Subsystem 

NMSS 

Nascom Manual Scheduling System 

NNMS 

Nascom Network Management System 

NNSG 

Nascom Network Scheduling Group 

NOAA 

National Oceanic and Atmospheric Administration 

NOCC 

Network Operations Control Center 

NOM 

Network Output Multiplexer 

NOS 

Nascom Operations System 

NOSIP 

Nascom Open Systems Interconnection Protocol 

NOSP 

Network Operations Support Plan 

NPR 

NASA Procurement Regulation 

NPRD 

Network Program Requirements Document 

NPSNET 

Nascom Packet Subnetwork 

NS 

Northrop Strip (2-letter Designator) 

NSA 

National Security Agency 

NSAP 

Network Service Assurance Plan 

NSDP 

Nascom System Development Plan 

NSGW 

Nascom Services Gateway 
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ACRONYM 

DEFINITION 

NTTF 

Network Training and Test Facility 

NU 

Network Upgrade 

NVTS 

NASA Video Transponder Service 

OAFB 

Onizuka Air Force Base 

OBC 

Onboard Computer 

OC 

Optical Carrier; Output Controller 

OCA 

Canadian Space Agency, Ottawa 

OCD 

Operations Concept Document 

OD 

Operations Directives 

OFTDS 

Orbital Flight Test Data System 

OH 

Ohio 

01 

Operational Instrumentation; Operator Interface 

OIS 

Operations Intercommunications System 

OJT 

On-the-Job Training 

OMB 

Office of Management and Budget 

OMF 

Operations Management Function 

OR 

Operations Requirements 

ORR 

Operations Readiness Review 

OS 

Operator Station 

OSC 

Office of Space Communications 

OSI 

Open Systems Interconnection 

OSSE 

Oriented Scintillation Spectrometer Experiment (Gamma Ray Observatory) 

OSTDS 

Office of Space Tracking and Data Systems 

OTDA 

Office of Tracking and Data Acquisition 

OTU 

Output Terminal Unit 

PA 

Pennsylvania; Public Affairs 

PABX 

Private Automatic Branch Exchange 

PACOR 

Packet Data Processor 

PAD 

Packet Assembly/Disassembly 

PAL 

Programmable Array Logic 

PAO 

Public Affairs Office 

PAR 

Project Authorization Review 

PASS 

Project Operations Control Center Applications Software Support 

PAT 

Patrick Air Force Base Station (3-letter Designator) 

PB 

Playback 
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ACRONYM 

DEFINITION 

PBF 

Payload Block Formatter 

PBX 

Private Branch Exchange 

PC/AT 

Personal Computer/ Advanced Technology 

PCM 

Pulse Code Modulation 

PDF 

Payload Data Formatter; Programmable Data Formatter 

PDFE 

Prototype DIF Front End 

PDIS 

Payload Data Interleaver Subsystem 

PDL 

Ponce de Leon Station (3-letter Designator) 

PDN 

Public Data Network 

PDP 

Computer Designator 

PDPF 

Packet Data Processing Facility 

PDR 

Preliminary Design Review 

PDRD 

Program Definition and Requirements Document 

PDSS 

Payload Data Services System 

PFOR 

Passive Fiber Optic Rack 

PIA 

Primary Interface Adapter 

PID 

Program Introduction Document 

PIOC 

Parallel Input/Output Channel 

PIP 

Payload Integration Plan; Project Implementation Plan 

PKM 

Perigee Kick Motor 

PM 

Phase Modulated 

PMI 

Programmable Modem Interface 

PMP 

Project Management Plan 

PMS 

Performance Monitoring System 

PMTC 

Pacific Missile Test Center 

PO 

Purchase Order 

POCC 

Project/Payload Operations Control Center 

POIC 

Payload Operations Integration Center 

POLAR 

Polar Plasma Laboratory 

POP 

Point-of-Presence; Polar Orbiting Platform; Project Operating Plan 

PORTS 

POCC Operations Real-time Support 

PPF 

Payload Parameter Frame 

PPM 

Passes Per Month 

PR 

Procurement Request 

PRD 

Program Requirements Document 
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ACRONYM 

PSC 

PSCN 

PSDR 

PSN 

PSP 

PSS 

PT&T 

PTF 

PTP 

PTS 

PUMP 

PV 

PWDS 

Q 

QA 

QAF 

QAM 

R&D 

R/L 

RAC 

RAM 

RAP 

RO 

RCA 

RCC 

RD 

RENAISSANCE 

RFP 

RFSOC 

RGCS 

RIC 

RIDS 

RMOC 

ROP 

RSO 


DEFINITION 

Platform Support Center 

Program Support Communications Network 

Preliminary System Design Review 

Packet Switch Node; Packet Switching Network 

Program Support Plan 

Portable Spacecraft Simulator 

Pacific Telephone and Telegraph 

Payload Test Facility (Space Telescope) 

Point Pillar Station (3-letter Designator) 

Pneumatic Tube Subsystem 

POCC Management Utilization Prositions 

Photovoltaic 

Protected Wire Distribution System 
Quadrature (Signal) 

Quality Assurance 

Quick Access Facility (Western Range, VAFB) 

Quadrature Amplitude Modulation 
Research and Development 
Return Link 

Remote Analysis Computer (Upper Atmosphere Research Satellite) 

Random Access Memory 
Restricted Access Processor 
Receive Only 

Radio Corporation of America 
Range Control Center 
Receive Data 

Reusable Network Architecture for Interoperable Space Science Analysis, Navigation, 
and Control Environment initiative. 

Request for Proposal 

Radio Frequency Simulation Operations Center 
Request for Ground Communications Service 
Remote Information Center 
Rockwell Integrated Data System 
Remote Mission Operations Center 
Receive-only Printer 
Range Safety Officer 
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ACRONYM 

DEFINITION 

RSS 

Rotating Service Structure 

RT 

Real Time 

RTC 

Real-time Clock 

RTOP 

Research Technology Objectives and Plans 

RTVE 

Radio Television Espanola 

S/CITF 

Spacecraft Integration and Test Facility 

S/N 

Signal-to-Noise 

SAMPEX 

Solar Anomalous and Magnetospheric Particle Explorer 

SAR 

Search and Rescue; Synthetic Aperture Radar 

SATCOM 

Satellite Communications 

SC 

Switching Computer 

SCAMA 

Switching, Conferencing, and Monitoring Arrangement 

SCE 

Spacecraft Command Encoder 

SCE MUX 

Spacecraft Command Encoder Multiplexer 

Sd 

Science Institute (Space Telescope) 

SCM 

Shift Communications Manager 

SCPC 

Single-Channel-per-Carrier 

SCR 

Serial Receive Clock; Strip Chart Recorder 

SCTE 

Serial Clock Transmit Extf, al 

SCVM 

Shuttle Command and Voice Multiplexer 

SD 

Send Data; South Dakota 

SDP 

System Development Plan 

SDPC 

Shuttle Data Processing Complex 

SDPF 

Sensor Data Processing Facility 

SDR 

System Design Review 

SDS 

System Design Specifications 

SDSS 

Shuttle Data Select Switch 

SEAS 

Systems, Engineering, and Analysis Support 

SEB 

Source Evaluation Board 

SEE 

Sustaining Engineering Element 

SEF 

Sustaining Engineering Facility 

SELV 

Small Expendable Launch Vehicle 

SEM 

Space Environment Monitoring 

SEMIS 

System Engineering Management Information System 

SESNET 

Space Earth Sciences Network 

SF 

Single Frequency 


OMOINAL PAGE tS 
OF POOR QUALITY 
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ACRONYM 

DEFINITION 

SFDU 

Standard Format Data Units 

SFOF 

Space Flight Operations Facility (Jet Propulsion Laboratory) 

SFU 

Space Flyer Unit 

SGL 

Space-to-G round Link 

SHO 

Schedule Orders 

SIOC 

Serial Input/Output Controller 

SIP 

Systems Implementation Plan 

SIPS 

Signal Input Processor System 

SKR 

Serial KG Recombiner 

SL 

Spacelab 

SLDPF 

Spacelab Data Processing Facility (Goddard Space Flight Center) 

SLPO 

Spacelab Program Office 

SM 

Statistical Multiplexer 

SMA 

S-band Multiple Access 

SMCC 

Shuttle Mission Control Center 

SMDS 

Statistical Multiplexer Data System 

SMEX 

Small Explorer 

SMP 

System Management Plan 

SN 

Space Network 

SNI 

San Nicholas Island (3-letter Designator) 

SNIP 

Space Network Interoperability Panel 

SNMP 

Simple Network Management Protocol 

SNR 

Signal-to-Noise Ratio 

SOC 

Simulation Operations Center (Goddard Space Flight Center) 

SOCC 

Satellite Operations Control Center (NOAA Suitland, MD) 

SOGS 

Science Operations Ground System (Space Telescope) 

SOHO 

Solar Heliospheric Observatory 

SOM 

Start of Message 

SONET 

Synchronous Optical Network 

SOW 

Statement of Work 

SPADE 

Single Channel per Carrier Pulse Code Modulation Multiple Access 

SPC 

Signal Processing Center 

SPDM 

Special Purpose Dexterous Manipulator 

SPIF 

Shuttle/POCC Interface Facility 

SPK 

Scott Peak Station (3-letter Designator) 
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ACRONYM 

DEFINITION 

SPOT-C 

System Probatoire d'Observation de la Terra-C 

SPPO 

Spacelab Payload Project Office 

SPX 

Simplex 

SR 

Special Routing 

SRB 

System Review Board 

SRR 

System Requirements Review 

SRT 

Supporting Research Technology 

SS 

Space Shuttle 

SSA 

S-band Single Access 

SSAI 

Science Systems and Applications, Inc. 

SSC 

Science Support Center 

SSCC 

Space Station Control Center 

SSCN 

Scientific Satellite Communications Network 

SSG 

System Support Group 

SSIO 

Spacelab Engineering Data Designator 

SSP 

Space Shuttle Program 

SSRMS 

Space Station Remote Manipulator System 

ST 

Space Telescope 

STADAN 

Satellite Tracking and Data Acquisition 

STARTCOW 

Warm Start of the COW Applications 

STC 

System Test Complex 

STD 

Standard 

STDN 

SpaceflightTracking and Data Network 

STGT 

Second TDRSS Ground Terminal 

STOCC 

Space Telescope Operations Control Center 

STOMS 

Space Telescope Observatory Management System 

STPr 

System Test Procedures 

STR 

System Test Review 

STS 

Space Transportation System 

SUE 

Shuttle-unique Echo-Equipment; System Utilization Enhancement 

SUSTS 

SN User Simulation and Test System 

SWAS 

Submillimeter Wave Astronomy Satellite 

T&DA 

Tracking and Data Acquisition 

TAC 

Telemetry and Command Processor 

TAGS 

Text and Graphics System 
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DEFINITION 

TAL 

Transoceanic Abort Landing 

TaSC 

Tanegashima Space Center 

TAT-5 

Trans-Atlantic Submarine Cable - 5 

TAT-6 

Trans-Atlantic Submarine Cable - 6 

TAV 

Test and Verification 

TBD 

To Be Determined 

TBS 

To Be Supplied 

TCC 

Time Division Multiple Access Network Control Center 

TCF 

Technical Control Facility 

TCI 

Tracking and Data Relay Satellite System Command Interface 

TCOPS 

Trajectory Computation and Orbital Products System 

TCS 

Technical Control Systems; Oak Hanger Tracking Station (DoD Facility) 

TCTS 

Traffic and Configuration Time Schedule 

TDM 

Time Division Multiplex 

TDMA 

Time Division Multiple Access 

TDPS 

Tracking Data Processor System 

TDRS 

Tracking and Data Relay Satellite 

TDRS II 

Tracking and Data Relay Satellite II 

TDRSS 

Tracking and Data Relay Satellite System 

TDS 

Tracking Data System 

TELCO 

Telephone Company 

TELECOM 

Goddard Space Flight Center Telecommunications Network 

TELECOM (A) 

Australian Telephone Company 

TELOPS 

Telemetry Online Processing System 

TGS 

Transportable Ground Station 

Tl 

Texas Instruments 

TID 

Time Independent Data 

TIMED 

Thermosphere, Ionosphere, Mesophere Energetics and Dynamics 

TIMED-H 

TIMED High Inclination 

TIMED-L 

TIMED Low Inclination 

TIP 

Transaction Interface Processor 

TIPIT 

Telemetry Input Processing into Telemetry Online Processing System 

TM 

Thematic Mapper 

TMIS 

Technical Management Information System 

TOCCT&C 

TDRSS Operations Control Center Tracking and Command 
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ACRONYM 

DEFINITION 

TOMS-EP 

Total Ozone Mapping Spectrometer-Earth Probe 

TPC 

Telemetry Preprocessing Computer 

TRANSPAC 

Trans-Pacific Submarine Cable 

TRW 

Thompson Ramo Wolridge 

TS 

Timing Subsystem; Transport Subsystem 

TSC 

Technical Subcommittees 

TT&C 

Tracking, Telemetry, and Command 

TTC&M 

Tracking, Telemetry Control and Monitoring 

TTY 

Teletype 

TV 

Television 

TVOC 

Television Operations Center 

TVSS 

Television and Video Switching Subsystem 

TX 

Texas 

U 

Univac; Utilities 

U-BUSS 

Utilities Buss 

U.S. 

United States 

UAF 

University of Alaska at Fairbanks 

UARS 

Upper Atmosphere Research Satellite 

UDS 

Universal Documentation System 

UHF 

Ultra-high Frequency 

UK 

United Kingdom 

UK/OCC 

United Kingdom/Operational Control Center 

UMSOC 

University of Maryland Science Operations Center 

UNH 

University of New Hampshire 

UPS 

Uninterruptable Power Supply; User Planning System 

USAEPG 

United States Army Electronic Proving Ground 

USAF 

United States Air Force 

USAF/SD 

United States Air Force/Space Division 

USN 

United States Navy 

V/D 

Voice/Data 

VA 

Virginia 

VAFB 

Vandenberg Air Force Base 

VANS 

VAFB 9-meter System 

VC 

Video Conferencing 

VCDU 

Virtual Channel Data Unit 
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DEFINITION 

VCSM 

Virtual Channel Sorter Multiplexer 

VDS 

Voice Distribution System 

VEEGA 

Venus Earth Gravity Assist 

VF 

Voice Frequency 

VFI 

Verification Flight Instrumentation; VCSM/FDDI Interface 

VFTG 

Voice Frequency Telegraph 

VHF 

Very-high Frequency 

VIP 

Virtual Interface Processor 

VIS 

Voice Intercom Subsystem 

VLBI 

Very Long Baseline Interferometry 

VLSI 

Very Large Scale Integration 

VNB 

Vandenberg Air Force Base (3-letter Designator) 

VPF 

Vertical Processing Facility (Eastern Range) 

VSB 

Vestigial Sideband 

VSS 

Voice Switching System 

WA 

Washington 

WAD 

Work Authorization Document 

WAN 

Wide Area Network 

WBA 

Wideband Adaptor 

WBDS 

Wideband Data System 

WCSC 

West Coast Switching Center (Jet Propulsion Laboratory) 

WECO 

Western Electric Company 

WESTAR 

Western Union Domestic Satellite 

WFF 

Wallops Flight Facility 

WHS 

White Sands Missile Range (3-letter Designator) 

WIND 

Interplanetary Physics Laboratory 

WLPS 

Wallops Flight Facility 

WLR 

Wideband Loop Repeater 

WOTS 

Wallops Orbital Tracking Station 

WPM 

Words per Minute 

WPS 

Wallops S-band Station (3-letter Designator) 

WR 

Western Range 

WSC 

White Sands Complex 

WSGT 

White Sands Ground Terminal 

WSGT-U 

WSGT Upgrade 
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ACRONYM 

DEFINITION 

WSMR 

White Sands Missile Range 

WSNS 

WTR Shuttle Network System 

WSTF 

White Sands Test Facility 

WU 

Western Union 

WUI 

Western Union International 

WV 

West Virginia 

XRI 

X-Ray Imager 

XRS 

X-Ray Solar; X-Ray Spectrometer 

XTERM 

XTerminal 

XY 

Building Designator at Cape Canaveral Air Force Station 

ZOE 

Zone of Exclusion 

lOOUNIs 

User-Network Interfaces 
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The information contained in this appendix has 
been extracted from the July 1993 edition of JPL's 
"Deep Space Network Mission Support Require- 
ments" (870-14) Rev. AM. 

This appendix presents a brief description of specific 
support requirements for each of the following 
missions (the alpha-numeric entries in the left-hand 
column refer to the paragraph in Appendix C where 
the mission is described : 


PARAGRAPH NAME OF PLANNED MISSION PAGE 

C.1 

Advanced X-Ray 
Astrophysics Facility 

C-1 

C.2 

CASSINI 

C-2 

C.3 

Earth Observing System 

C-2 

C.4 

Engineering Test Satellite VI 
(ETS-VI) 

C-2 

C.5 

European Telecommunications 
Satellite II (EUTELSAT II) 

C-3 

C.6 

Fast Auroral Snapshot 
Explorer (FAST) 

C-3 

C.7 

Geostationary 
Meteorological Satellite-5 
(GMS-5) 

C-3 

C.8 

Geostationary Operational 
Environmental Satellite 
(GOES l-M) 

C-4 

C.9 

HELIOS-1 and -2 

C-4 

C.10 

International Solar Terrestrial 
Physics Program (ISTP) 
Collaborative Solar 
Terrestrial Research (COSTR) 
Initiative (SOHO and 
CLUSTER missions) 

C-5 

C.11 

International Solar 
Terrestrial Physics Program 
(ISTP) Global Geospace 
Science (GGS) Initiative 
(WIND and Polar missions) 

C-5 

C.12 

National Oceanic and Atmospheric 
Administration-K, -L, -M, -N 
(NOAA-K, -L, -M, -N) 

C-6 

C.13 

Space Flyer Unit (SFU) 

C-6 

C.14 

Submillimeter Wave 
Astronomy Satellite (SWAS) 

C-6 


C.15 

Telecom 2-C 

C-7 

C.16 

Total Ozone Mapping 
Spectrometer/Earth Probe 

C-7 

C.17 

Tracking and Data Relay 
Satellite (TDRS-G) 

C-7 

C.18 

Tropical Rainfall Measuring 
Mission 

C-8 

C.19 

X-Ray Timing Explorer 

C-8 


DESCRIPTIONS OF PLANNED MISSIONS 


C.1 ADVANCED X-RAY ASTROPHYSICS FACILITY 
Launch: December 1999 


MISSION DESCRIPTION 

The Advanced X-Ray Astrophysics Facility (AXAF) 
missions will consist of two free-flying observatory 
spacecraft that will perform x-ray astronomy re- 
search. AXAF is a follow-on project to the High En- 
ergy Astrophysics Observatory (HEAO) program that 
will provide about 10 times the resolution and 100 
times the sensitivity of HEAO missions. AXAF-S 
(Spectroscopy) is the second of the two missions and 
will contain one instrument, the X-Ray Spectrometer 
(XRS). 

FLIGHT PROFILE 

The AXAF-S will be launched by a Delta II launch ve- 
hicle from VAFB into a 650 km circular sun synchro- 
nous orbit, with an inclination of 97.9 degrees. 

COVERAGE GOALS 

The AXAF spacecraft will be TDRSS compatible and 
be supported by the Space Network. The DSN 26- 
meter antennas at each complex will provide emer- 
gency support, as requested by GSFC. 

DATA RATES 

Telemetry 1,4, or 32 kb/s realtime 

256 or 5 1 2 kb/s playback 

Command 2.0 kb/s 
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C.2 CASSINI 


Launch: October 06, 1997 

MISSION DESCRIPTION 

Cassini is a deep space mission planned for launch in 
October 1997 to arrive at Saturn in June 2004. After 
arrival at Saturn, Cassini will send a probe into the 
Titan atmosphere, then continue on a 4-year 
satellite tour, using repeated gravity assists of Titan 
to shape the trajectory to satisfy science objectives. 

FLIGHT PROFILE 

The spacecraft will be launched from Cape 
Canaveral as a single payload using a Titan IV and 
Centaur upper stage as the launch vehicle. The 
Centaur second burn will inject Cassini into the 
interplanetary trajectory. 

Cassini will use gravity assists with Venus, Earth, and 
Jupiter to provide the required energy to arrive at 
Saturn. Trajectory correction maneuvers and cali- 
bration activities will be performed during the 
interplanetary cruise, as well as limited science data 


collection. 


Event 

Date 

Launch 

06 Oct 1997 

Venus Flyby 

21 Apr 1998 

Venus Flyby 

20 Jun 1999 

Earth Flyby 

16 Aug 1999 

Enter Asteroid Belt 

12 Dec 1999 

Jupiter Flyby 

30 Dec 2000 

Saturn Orbit Insertion 

25 Jun 2004 

Probe Separation 

09 Jan 2005 

Probe Entry 

03 Jan 2005 

End of Mission 

25 Jun 2008 


COVERAGE GOALS 

The spacecraft will operate on the Low Gain 
Antenna during most of the first 2 years of cruise 
requiring 70-meter antenna support. If the 70- 
meter antennas are not implemented with X-band 
uplink capability, simultaneous 34-meter coverage 
will be required to meet the command and 
navigation requirements. 


support during the 6 days of high-level activities for 
each 30-day orbit. 

DATA RATES 


Telemetry 

X-band 

5 b/sto 285 kb/s 


Ka-band 

Carrier only 


S-band 

Carrier only 

Command 

X-band 

7.81 25 to 500 b/s 

C.3 EARTH OBSERVING SYSTEM 

Launch: 

AMI 

June 1998 


AEROI 

June 2000 


PM1 

December 2000 


ALT1 

June 2002 


CHEM1 

December 2002 


MISSION DESCRIPTION 


The Earth Observing System (EOS) program involves 
the operation of numerous instruments on multiple 
spacecraft placed in polar and midinclination orbits 
in support of multiple disciplines within the Earth 
science user community. The EOS mission is com- 
posed of several series of flights beginning with the 
EOS-AM1 flight in 1998. The other EOS series in- 
clude PM, AERO (Aerosols), ALT (Altimetry), and 
CHEM (Chemistry) flights. Each spacecraft has a pro- 
jected lifetime of 5 years with replacement space- 
craft to provide a total series lifetime of 15 years. s*/ 

AERO flights are an exception with a 3 year project- 
ed lifetime and additional replacements to support 
the 1 5 year objective. 

FLIGHT PROFILE 


The EOS-AM and PM series missions will be launched 
from VAFB by Atlas II AS launch vehicles into 705 km 
sun-synchronous circular orbits with 98.2 degree in- 
clinations. AERO, ALT, and CHEM series missions are 
under study to determine launch vehicle and orbit 
requirements. 

COVERAGE GOALS 

Primary mission support will be provided by the 
TDRSS. The DSN will be available for emergency 
support, if required. 


The 34-meter HEF antennas will provide one 
tracking pass plus one Delta VLBI pass per week 
during cruise operations, and continuous coverage 
around gravity assists and maneuvers. 


DATA RATES 

Telemetry 


16 kb/s realtime 
512 kb/s playback 


During Saturn orbital operations, one 34-meter 
BWG pass per day for the 24 days of cruise-like 
activities, and continuous array 34-meter BWG 


Command 


2.0 kb/s 
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C-4 ENGINEERING TEST SATELLITE VI (ETS-VI) 

Launch: August, 1994 
MISSION DESCRIPTION 

The ETS-VI is being developed by the National 
Development Agency of Japan (NASDA) as the third 
Japanese three-axis stabilized engineering test 
satellite to establish the 2-ton geostationary 
operational satellite bus system. High performance 
satellite communications technology for future 
operational satellites will be demonstrated. Mission 
life expectancy is 10 years. 

FLIGHT PROFILE 

The ETS-VI satellite will be launched by a H-ll launch 
vehicle from Tanegashima Space Center (TaSC) in 
southern Japan. The mission design follows the 
conventional injection sequence into synchronous 
orbit via parking, transfer, and drift orbits. The 
satellite is to be located at 154 degrees east 
longitude. 

COVERAGE GOALS 

Coverage will consist of all the 26-meter antennas 
with 34-meter antennas at Madrid and Canberra as 
backup. Maximum support will consist of two 8- 
hour tracks per station for the first 7 days, plus 
contingency support, if required. 

DATA RATES 

Telemetry 512, 2048 b/s 

Command 1000 b/s 

C.5 EUROPEAN TELECOMMUNICATIONS SATELLITE 
II (EUTELSAT II) 

Launch: F-6 December 1994 

MISSION DESCRIPTION 

EUTELSAT II is a regional public telecommunications 
system for Europe. The services to be provided are 
telephone and television. Each satellite lifetime is 
expected to be 7 years. 

FLIGHT PROFILE 

EUTELSAT II satellites are launched using the Ariane 
4 launch vehicle from Kourou, French Guiana. The 
satellites will be placed at a geostationary orbit 
within the arcs 6 to 19 degrees east, or 26 to 36 
degrees east. 


COVERAGE GOALS 

The DSN 26-meter antennas at Goldstone and 
Canberra will support the transfer and drift orbits. 
Maximum support will consist of a 7-day period 
following launch, plus 14 days contingency support. 

DATA RATES 

Telemetry 512 b/s 

Command 500 b/s 

C.6 FAST AURORAL SNAPSHOT EXPLORER (FAST) 
Launch: August 1994 
MISSION DESCRIPTION 

FAST is the second explorer of the Small Explorer 
multi-mission program. Its primary objective is to 
investigate the plasma physics of the low-altitude 
auroral zone. 

FUGHT PROFILE 

FAST will be launched on a Pegasus Small 
Expendable Launch Vehicle (SELV) from the West 
Coast. The spacecraft will be launched into a 
nominal elliptical orbit of 350 km by 4200 km with 
an inclination of 83 degrees. 

COVERAGE GOALS 

The DSN 26-meter antennas will support three to six 
30-minute contacts per day during launch and early 
orbit phase. WFF and the DSN will be backup to 
Poker Flats, Alaska and Kiruna, Sweden when 
apogee is in the northern hemisphere. When 
apogee is in the southern hemisphere, WFF and the 
DSN are prime support stations. 

DATA RATES 

Telemetry 4.0 kb/s Real-time 

900 kb/s or 1 .5 Mb/s Playback 

Command 2.0 kb/s 


C.7 GEOSTATIONARY METEOROLOGICAL SATEL- 
LITE-5 (GMS-5) 

Launch: February 1995 

MISSION DESCRIPTION 

NASDA is developing GMS-5 as a continuation of 
their geostationary, spin stabilized, weather 
satellite program. The mission is to observe 
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cataclysmic events such as hurricanes, typhoons and 
regional weather phenomena; day and night 
observations of regional weather; relay of 
meteorological observation data from surface 
collection points (ships, buoys and weather stations) 
to data processing center in Japan; and transmission 
of processed image data for facsimile distribution to 
western Pacific areas. 

FLIGHT PROFILE 

GMS-5 will be launched from TaSC in southern 
Japan by a H-ll launch vehicle. Apogee Kick Motor 
(AKM) firing will occur at the 2nd (nominal) or 4th 
(contingency) apogee. After AKM firing, drift phase 
orbital and attitude maneuvers wijl be performed to 
place the spacecraft at its final geostationary 
position. 

COVERAGE GOALS 

The coverage will consist of the 26-meter antennas 
as prime and the Madrid 34-meter antenna as 
backup support for launch through drift orbit. 
Maximum support will be two 8-hour tracks per 
station for a 7-day period plus 23 days of 
contingency support from all complexes. 

DATA RATES 

Telemetry 250 b/s 

Command 128 b/s 

C.8 GEOSTATIONARY OPERATIONAL ENVIRON- 
MENTAL SATELUTE (GOES) 

Launch: GOES-I April 1994 
GOES-J March 1995 
GOES-K December 1998 
GOES-L December 1999 
GOES-M December 2003 

MISSION DESCRIPTION 

The objectives of the GOES program are to provide a 
satellite system that meets the National 
Environmental Satellite Data and Information 
Service (NESDIS) requirements specified by NOAA. 
These requirements include an Imager and Sounder 
system, a Space Environment Monitoring (SEM) 
System, a Data Collection System, and a Search and 
Rescue (SAR) monitoring system. The SEM 
subsystems include a Solar X-Ray Sensor (XRS), an 
Energetic Particle Sensor (EPS), a High-Energy 
Proton and Alpha Detector (HEPAD), a 
Magnetometer, and an X-Ray Imager (XRI). Each 
spacecraft will be designed to meet specified 
performance requirements for a 5 year period. 


FLIGHT PROFILE 

GOES satellites will be launched from the CCAFS 
using Atlas Centaur expendable launch vehicles. 
The satellites have been designed for shuttle 
retrieval in the event of a Perigee Kick Motor (PKM) 
or similar failure that would prevent the spacecraft 
from leaving low Earth orbit. 

After Atlas/Centaur separation, the Centaur upper 
stage performs two main engine burns to place the 
satellite into an elliptical orbit with the apogee close 
to geosynchronous altitude. NOAA will perform 
control maneuvers to circularize the prbit and drift 
the satellites into the operational geostationary 
locations. f 

COVERAGE GOALS 

The DSN 26-meter stations at all complexes will 
provide telemetry, command and tracking support 
following launch through completion of transfer 
and drift orbits. Contingency support will be provid- 
ed while the spacecraft undergoes on-station check- 
out. After the initial 30-45 days, the DSN is com- 
mitted for emergency support. Contingency and 
emergency support will be provided by Goldstone 
only. 

DATA RATES 

Telemetry 2.0 kb/s 

Command 250 b/s 

C.9 HELIOS-1 AND -2 (REIMBURSABLE) 

Launch: Helios-1 December 1994 
Helios-2 September 1999 

MISSION DESCRIPTION 

The Helios program will provide Italian, Spanish and 
French defense systems with remote sensing data. 
Each satellite will have one high-resolution instru- 
ment and two tape recorders that will be used to 
obtain constant data under optimal illumination 
conditions. 

FLIGHT PROFILE 

Both satellites will be launched from the Centre 
Spatial Guyanis in French Guiana on Ariane-4 launch 
vehicles. The satellites will be injected into the same 
near-circular orbits separated by 180-degrees. 

COVERAGE GOALS 

The Goldstone 26-meter station may provide 
telemetry, command and tracking support on 
revolutions 2 and 3 only. 
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DATA RATES 

Telemetry 4.096 kb/s 

Command 2.0 kb/s 

C.10 INTERNATIONAL SOLAR TERRESTRIAL 

PHYSICS PROGRAM (ISTP) COLLABORATIVE 
SOLAR TERRESTRIAL RESEARCH (COSTR) 
INITIATIVE (SOHO AND CLUSTER MISSIONS) 

Launch: SOHO July 1995 

CLUSTER December 1995 

MISSION DESCRIPTION 

The COSTR initiative will combine resources and 
scientific communities on an international scale to 
undertake the development of instruments and 
their appropriate support elements, along with 
ground based theory investigations in the context of 
a comprehensive program of solar-terrestrial 
physics. The Geomagnetic Tail Laboratory 
(GEOTAIL) furnished by ISAS and launched by NASA 
in July 1992 was the first spacecraft of the ISTP 
program. The Solar and Heliospheric Observatory 
(SOHO) and the Plasma Turbulence Laboratories 
(CLUSTER) will be furnished by ESA. This program 
will study the overall balance and the nature of 
solar-terrestrial interaction of the Geospace region. 

FUGHT PROFILE 

SOHO will be launched from CCAFS on a Atlas II 
launch vehicle and placed into a large Halo orbit 
about the LI libration point. The CLUSTER 
spacecraft will be launched by an Ariane from 
Kourou, French Guiana into a four-spacecraft 
formation in a polar orbit 4 x 22 Earth Radii, with 
apogee near the Equator. 

COVERAGE GOALS 

Data acquisition from SOHO will consist of one eight 
hour contact per day for real-time data, and three 
1.3 hour contacts for acquisition of tape recorder 
data. This mode of operation will be in effect 
approximately ten months per year. The remaining 
two months require continuous real-time data 
acquisition. The CLUSTER support will be limited to 
acquisition of plasma wave wideband data, two 
hours per orbit from three or four spacecraft. The 
DSN 26-meter antennas will be the prime support 
facilities with 34-meter antennas as backup. 


DATA RATES 
SOHO 

Telemetry 245.7 kb/s real-time 

245.7 kb/s playback 

Command 2.0 kb/s 

CLUSTER 

Telemetry 240 kb/s playback 

Command N/A 

C.11 INTERNATIONAL SOLAR TERRESTRIAL 



Launch: WIND April 1994 

POLAR June 1994 

MISSION DESCRIPTION 

The WIND and POLAR satellites are being developed 
by NASA as components of the ISTP program. These 
two spacecraft will be launched as the second and 
third missions in the program. The GGS objectives 
are to quantitatively assess the processes in the Sun- 
Earth interaction chain by the use of simultaneous 
instrument measurements from spacecraft placed in 
complementary orbits. 

FUGHT PROFILE 

Both spacecraft will be launched on Delta II 7925 
expendable launch vehicles. WIND will be launched 
from CCAFS into a sun-side apogee double-lunar 
swing-by orbit for a period of one year, after which 
the spacecraft may be transferred to a Sun-Earth L-1 
Halo orbit. POLAR will be launched from VAFB into 
a 2 earth radii by 9 earth radii Polar orbit, with 
apogee near the North Pole. 

COVERAGE GOALS 

The WIND spacecraft will carry a NASA standard S- 
band transponder. One 2.08-hour support interval 
each day will be required for receiving tape recorder 
playback data. Real-time telemetry for spacecraft 
and instrument-performance monitoring will be 
received on a subcarrier simultaneous with the tape 
recorder playback. The spacecraft requires that 
command support periods be no more than 36 hours 
apart during the prime mission. The DSN 26-meter 
antennas are prime support with the 34-meter 


DSN MISSIONS C-5 





540-030 

FY94-2 


antennas used for backup support, or when 
insufficient link margins require their use. 

The POLAR spacecraft will also carry a NASA 
standard S-band transponder. Four support 
intervals per day of approximately 45 minutes in 
duration will be required for receiving tape recorder 
playback data. Up to 12 hours per day for the first 
month and 3.6 hours daily thereafter will be needed 
for receiving real-time wide-band data. Real-time 
telemetry for spacecraft and instrument per- 
formance monitoring will be received on a sub- 
carrier simultaneous with either the tape recorder 
playback or wideband data on the main carrier. The 
26-meter antennas are prime for support with the 
34-meter antennas used for backup support. 

DATA RATES 

WIND 

Telemetry 5.565 or 11.3 kb/s real-time 

32, 64 or 128 kb/s playback 

Command 250 b/s 

POLAR 

Telemetry 55.65 kb/s real-time 

256 or 512 kb/s playback 

Command 1 .0 kb/s 


C.12 NATIONAL OCEANIC AND ATMOSPHERIC 
ADMINISTRATION-K. -L. -M. -N (NOAA-K. -L 
M.-N) 

Launch: NOAA-K May 1995 

NOAA-L August 1996 
NOAA-M November 1997 
NOAA-N May 2000 

MISSION DESCRIPTION 

This third-generation series of NOAA missions will 
provide advanced operational satellites and sensors 
for use in the National Environmental Satellite Data 
and Information Service (NESDIS). 

FLIGHT PROFILE 

All satellites will be launched from VAFB on Titan II 
expendable launch vehicles. The spacecraft will be 
launched into near-polar, circular, sun-synchronous 
orbits. 


COVERAGE GOALS 

The DSN 26-meter stations will support 
approximately six 12-minute contacts per day during 
launch and early orbit phase. The operational 
mission phase will be supported by NOAA stations 
with possible DSN backup support requirements. 

DATA RATES 

Telemetry 8.32 and 16.64 kb/s 

Command 2.0 kb/s 

C.13 SPACE FLYER UNIT (SFU) (REIMBURSABLE) 

Launch: February 1, 1995 
MISSION DESCRIPTION 

The SFU is an unmanned, reusable, and retrievable 
free-flying platform for multipurpose use. The 
spacecraft will carry seven individual experiments to 
be completed during its mission period. Upon com- 
pletion, the SFU spacecraft is to be recovered by the 
space shuttle. 

FUGHT PROFILE 

The SFU spacecraft will be launched on an H-ll 
launch vehicle from Tanegashima Space Center 
(TASC) in southern Japan into a low-Earth orbit of 
400 km perigee and 500 km apogee. 

COVERAGE GOALS 

The DSN 26-meter stations will support the early 
orbit mission phase and SFU retrieval by the shuttle. 
DATA RATES 

Telemetry 1 .0, 4.0, 8.0, and 1 28 kb/s 

Command 1.0 kb/s 

C.14 SUBMILUMETER WAVE ASTRONOMY 
SATELLITE (SWAS) 

Launch: June 29, 1995 

MISSION DESCRIPTION 

SWAS is a Small Explorer mission designed to study 
molecular clouds in the galactic plane, providing a 
mini and full survey of the clouds, leading towards 
the development of maps. 
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FLIGHT PROFILE 

SWAS will be launched on a Pegasus Small 
Expendable Launch Vehicle (SELV) from Wallops 
Flight Facility (WFF). 

COVERAGE GOALS 

The DSN may support two to four 10-minute 
contacts per day as a backup to Wallops Flight 
Facility or Poker Flats. 

DATA RATES 

Telemetry 9 or 18 kb/s real-time 

1.8 or 900 kb/s playback 

Command 2.0 kb/s 

C.15 TELECOM 2-C 

Launch: January 1996 
MISSION DESCRIPTION 

The Telecom 2-C mission will provide high-speed da- 
ta link applications, telephone, and television ser- 
vice between France and overseas territories as a 
follow-on to earlier spacecraft. 

FLIGHT PROFILE 

Telecom 2-C will be launched by an Ariane-4 from 
the Centre Spatial Guyanis in French Guiana. After 
the final Apogee Kick Motor firing, the spacecraft 
will be in a geostationary orbit. 

COVERAGE GOALS 

The Goldstone and Canberra stations will provide 
coverage during the transfer and drift orbits consist- 
ing of two 8-hour tracks per station for a 7-day pe- 
riod, plus 14 days of contingency support. 

DATA RATES 

Telemetry 320 b/s 

Command 1.0 kb/s 

C.16 TOTAL OZONE MAPPING SPECTROMETER/ 
EARTH PROBE 

Launch: May 1994 

MISSION DESCRIPTION 

The Total Ozone Mapping Spectrometer/Earth 
Probe (TOMS/EP) mission will accomplish a 
contiguous survey of the Earth's global ozone layer 
each day. The spacecraft will be capable of 


autonomous operation for at least 24 hours without 
ground contact. Two contingency modes (safety- 
hold and sun pointing) will maintain the spacecraft 
in power- and thermal-safe conditions. 

FLIGHT PROFILE 

The TOMS/EP will be launched by a Pegasus launch 
vehicle from the West Coast into a 235 km orbit, 
with an inclination of 99.3 degrees. The TOMS/EP 
Orbit Adjust Subsystem will be used to lift the 
spacecraft into a 955 km operational orbit. 

COVERAGE GOALS 

The DSN 26-meter antennas at each complex will 
provide primary mission support, as requested by 
GSFC. 

DATA RATES 

Telemetry 1.125 kb/s real-time 

50.625 or 202.5 kb/s playback 

Command 2.0 kb/s 

C.17 TRACKING AND DATA RELAY SATELLITE 
(TDRS-G) 

Launch: June 29, 1995 
MISSION DESCRIPTION 

The Tracking and Data Relay Satellites rejay 
communication signals between low Earth-orbiting 
spacecraft and the ground terminal at White Sands, 
New Mexico. This relay is accomplished through 
two types of communications links: (1) a multiple- 
access system with one 30-element S-band phased- 
array antenna system; and (2) two 4.8-meter single- 
access parabolic antennas operating at S- and Ku- 
band. 

FLIGHT PROFILE 

TDRS-G will be launched by the shuttle and 
deployed into a low Earth-orbit. Following 
deployment, the Inertial Upper Stage (IUS) will 
inject the satellite into an elliptical orbit that will be 
circularized to place the satellite into a 
geostationary position. Depending upon 
operational needs, the satellite will be drifted into 
the final operational location between 41 and 174 
degrees west longitude. 

COVERAGE GOALS 

The DSN supports launch and transfer orbit plus 
emergency support from Canberra, Goldstone and 
Madrid. The 26- and 34-meter antennas at each 
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complex are scheduled according to the specific 
flight profile for placing the spacecraft into the 
operational geostationary location. 

DATA RATES 

Telemetry 250 b/s or 1 .0 kb/s 

Command 2.0 kb/s 

C18 TROPICAL RAINFALL MEASURING MISSION 
Launch: August 1997 
MISSION DESCRIPTION 

The Tropical Rainfall Measuring Mission (TRMM) is 
an integral part of the NASA Mission to Planet Earth 
Program. The mission is to study the distribution 
and variability of precipitation and latent heat 
release over a multi-year data set. TRMM is a 
climate mission designed to determine the rate of 
rainfall and the total rainfall between the North and 
South latitudes of 35 degrees. The primary data set 
is the monthly average rainfall with a spatial 
resolution of 500 km. 

FUGHT PROFILE 

TRMM will be launched from Tanegashima, Japan 
on a H-ll launch vehicle. The spacecraft will be 
placed into a 380 km orbit and maneuvered to its 
operational altitude of 350 km approximately one 
month after launch. 

COVERAGE GOALS 

TRMM is a TDRSS compatible mission and will 
receive all primary support through the TDRSS. The 
DSN 26-meter antennas at each complex will 
provide contingency support when requested by 
GSFC. 


DATA RATES 

Telemetry 1 or 32 kb/s 

Command 2.0 kb/s 

C.1 9 X-RAY TIMING EXPLORER 

Launch: August 1995 

MISSION DESCRIPTION 

The X-Ray Timing Explorer (XTE) observatory will 
study a variety of x-ray sources including white 
dwarfs, accreting neutron stars, black holes, and 
active galactic nuclei. Measurements will be made 
over a wide range of photon energies from 2 to 
200 keV. The spacecraft will carry three 
instruments: the Proportional Counter Array (PCA), 
the All Sky Monitor (ASM), and the High Energy X- 
Ray Timing Experiment. 

FLIGHT PROFILE 

XTE will be placed into a 600 km circular orbit with a 
23 degree inclination by a Delta 7920 vehicle 
launched from CCAFS. 

COVERAGE GOALS 

Primary mission support will be provided by the 
TDRSS. The DSN will be available for emergency 
support, if required. 

DATA RATES 

Telemetry 32 and 1024 kb/s 

Command 2.0 kb/s 
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